annotate README @ 28:b1bc4d045a4b vamp-plugin-tester-v1.0

* Solaris build fixes

Vamp Plugin Tester
==================

This program tests Vamp audio feature extraction plugins
(http://vamp-plugins.org/) for certain common failure cases.

To test a single plugin, run vamp-plugin-tester with the name of your
plugin library and plugin identifier, separated by a colon.  For example,

  $ vamp-plugin-tester vamp-example-plugins:amplitudefollower

The plugin library must be installed in the Vamp plugin path (you
cannot give the path to the library file).


Options
=======

Supply the -a or --all option to tell vamp-plugin-tester to test all
plugins found in your Vamp path.

Supply the -v or --verbose option to tell vamp-plugin-tester to print
out the whole content of its returned feature log for diagnostic
purposes each time it prints an error or warning that arises from the
contents of a returned feature.

Supply the -n or --nondeterministic option to tell vamp-plugin-tester
that your plugins are expected to return different results each time
they are run.  The default behaviour is to treat different results on
separate runs with the same input data as an error.


Errors and Warnings
===================

Each test may cause one or several notes, warnings, or errors to be
printed.  A note is printed when behaviour is observed that may be
correct behaviour but that is not always anticipated by the plugin
developer.  A warning is printed when behaviour is observed that is
technically legal but that in practice most often happens by mistake.
An error is printed when behaviour is observed that cannot be correct.

vamp-plugin-tester prints all of its commentary to the standard
output.  Standard error is usually used for diagnostic output printed
by the plugins themselves.

In addition to reports, vamp-plugin-tester runs some tests that are
intended to provoke the plugin into unexpected behaviour such as
memory errors.  If vamp-plugin-tester crashes during a test, this may
be why.  If you have access to a memory checker utility such as
valgrind, you are advised to run vamp-plugin-tester under it so as to
be informed of any memory errors that do not happen to cause crashes
(as well as memory leaks).  The vamp-plugin-tester binaries
distributed by QMUL have been compiled with debug information
included, in order to facilitate this type of use.


Error and Warning Reference
===========================

 ** ERROR: Failed to load plugin

 The plugin could not be loaded.  Remember that the plugin must be
 installed in the Vamp plugin path.

 Normally this message will be preceded by one of the following
 errors:

   Invalid plugin key <key> in loadPlugin

    - The argument given to vamp-plugin-tester could not be split
      into library name and plugin identifier.  Check the usage
      description above.

   No library found in Vamp path for plugin <key>

    - No Vamp plugin library of that name was found in the Vamp path.
      This message will often be accompanied by one of the following
      errors; if it isn't, then that probably means the file did not
      exist at all.

   Plugin <id> not found in library <name>

    - The library was found and loaded and was apparently a valid
      Vamp plugin library, but it didn't contain a plugin of that id.
      Check you typed the id correctly, and if this is your library,
      check that the vampGetPluginDescriptor function returns the
      plugin descriptor properly.

   Unable to load library <name>

    - A dynamic library of that name was found, but the system library
      loader could not load it.  Perhaps it depends on another library
      that is not available, or it was built for the wrong architecture.
      There may be more information in the error message.

   No vampGetPluginDescriptor function found in library <name>

    - A dynamic library of that name was found and loaded, but it
      lacked the necessary public vampGetPluginDescriptor function.

      * Are you sure this is a Vamp plugin library?
      * If you made it, did you remember to include the global
        vampGetPluginDescriptor function in your library along with
	your plugin classes?
      * If you are using Visual C++, did you remember to mark the
        vampGetPluginDescriptor symbol exported, as described in
        the README.msvc file in the SDK?

 ** ERROR: (plugin|parameter|output) identifier <x> contains invalid characters

 An identifier contains characters other than the permitted set (ASCII
 lower and upper case letters, digits, "-" and "_" only).

 ** ERROR: <field> is empty

 A mandatory field, such as the name of a parameter or output,
 contains no text.

 ** WARNING: <field> is empty

 An optional field, such as the description of a parameter or output,
 contains no text.

 ** ERROR: Plugin parameter <x> maxValue <= minValue

 The minimum and maximum values given for a parameter are equal or in
 the wrong order.

 ** ERROR: Plugin parameter <x> defaultValue out of range

 The default value for a parameter is not within the range defined by
 the minimum and maximum values for the parameter.

 ** ERROR: Plugin parameter <x> is quantized, but quantize step is zero

 The quantizeStep value in a parameter with isQuantized true is set to
 zero.

 ** WARNING: Plugin parameter <x> value range is not a multiple of quantize step

 A parameter's stated maximum value is not one of the possible values
 obtained by adding multiples of the quantize step on to the minimum
 value.

 ** WARNING: Plugin parameter <x> has (more|fewer) value names than quantize steps

 A quantized parameter lists some value names for its quantize steps,
 but not the right number.
 
 ** WARNING: Plugin parameter <x> default value is not a multiple of quantize
 step beyond minimum

 The default value for a parameter is not a value that the user could
 actually obtain, if only offered the quantized values to choose from.

 ** ERROR: Data returned on nonexistent output

 The output number key for a returned feature is outside the range of
 outputs listed in the plugin's output descriptor list.

 ** NOTE: No results returned for output <x>

 The plugin returned no features on one of its outputs, when given a
 simple test file.  This may be perfectly reasonable behaviour, but
 you might like to know about it.

 ** NOTE: Plugin returns features with timestamps on OneSamplePerStep output
 ** NOTE: Plugin returns features with durations on OneSamplePerStep output

 Hosts will usually ignore timestamps and durations attached to any
 feature returned on a OneSamplePerStep output.

 ** ERROR: Plugin returns features with no timestamps on VariableSampleRate output

 Timestamps are mandatory on all features associated with a
 VariableSampleRate output.

 ** WARNING: Plugin returned one or more NaN/inf values

 The plugin returned features containing floating-point not-a-number
 or infinity values.  This warning may be associated with a test
 involving feeding some unexpected type of data to the plugin.
 
 ** ERROR: Consecutive runs with separate instances produce different results

 The plugin was constructed and run twice against the same input data,
 and returned different features each time.

 If you give the -n or --nondeterministic option, vamp-plugin-tester
 will downgrade this error to a note.

 ** ERROR: Consecutive runs with the same instance (using reset) produce different results

 The plugin was constructed, initialised, run against some input data,
 reset with a call to its reset() function, and run again against the
 same data; and it returned different features on each run.  This is
 often a sign of some simple error such as forgetting to implement
 reset().

 If you give the -n or --nondeterministic option, vamp-plugin-tester
 will downgrade this error to a note.

 ** ERROR: Simultaneous runs with separate instances produce different results

 Two instances of the plugin were constructed and run against the same
 input data, giving each block of data to one plugin's process call
 and then to the other's, "interleaving" the processing between the
 two instances (but within a single application thread); and the two
 instances returned different features.  This may indicate ill-advised
 use of static data shared between plugin instances.

 If you give the -n or --nondeterministic option, vamp-plugin-tester
 will downgrade this error to a note.

 ** WARNING: Consecutive runs with different starting timestamps produce the same result

 The plugin was run twice on the same audio data, but with different
 input timestamps, and it returned the same results each time.  While
 this is often unproblematic, it can indicate that a plugin failed to
 take the input timestamp into account when calculating its output
 timestamps (if any).

 If you give the -n or --nondeterministic option, vamp-plugin-tester
 will downgrade this warning to a note.

 ** ERROR: Explicitly setting current program to its supposed current value changes the results

 The plugin was constructed and run twice on the same data, once
 without changing its "program" setting, and again having set the
 program to the vaule returned by getCurrentProgram() (i.e. the same
 program that was supposed to be in effect already).  It returned
 different results for the two runs, suggesting that some internal
 data was changed in selectProgram in a way that differed from its
 default.

 If you give the -n or --nondeterministic option, vamp-plugin-tester
 will downgrade this error to a note.

 ** ERROR: Explicitly setting parameters to their supposed default values changes the results

 The plugin was constructed and run twice on the same data, once
 without changing any of its parameters, and again having set the
 parameters to their specified default values.  It returned different
 results for the two runs, suggesting that some internal data was
 changed when a parameter was set to its default, in a way that
 differed from the plugin's initially constructed state.

 If you give the -n or --nondeterministic option, vamp-plugin-tester
 will downgrade this error to a note.

 ** WARNING: Constructor takes some time to run: work should be deferred to initialise?

 The plugin took a long time to construct.  You should ensure that the
 constructor for the plugin runs as quickly as possible, because it
 may be called by a host that is only scanning the properties of all
 available plugins on startup.  Any serious initialisation work should
 be done in the initialise() function rather than the constructor.


Authors
=======

This program was written at the Centre for Digital Music at Queen
Mary, University of London, by Chris Cannam.  Copyright (c) 2009 QMUL.