Inconsistent behavior between vamp-simple-host and vampyhost

[pglushkov]

Hello all!
I've been recently experimenting with VAMP, tried to create my own plugin and work with it by means, provided in vamp-sdk. What I've yet discovered is that my implementation of simple testing plugin behaves differently when invoked by vamp-simple-host from vamp-sdk and by vampy host in Python3. Some more details:

1. I'm using Ubuntu 16.04. Due to being lazy, I've installed both vamp-sdk and vampy apt-get / pip correspondingly.

Version that is shown by vamp-simple-host:
Simple Vamp plugin host version: 1.5
Vamp API version: 2
Vamp SDK version: 2.5

Version shown by vampy-host:
vamp (1.1.0) (it's actually being shown by pip3 cause I could not find any 'vesrion' functions in vamp in Python)

2. My plugin is a very simple one. It has only 1 output with 'FixedSampleRate'. It uses length of the block and fills 'values' of the output Feature with vector of std::abs( input ). Yes, that might seem like a hack, but I wanted to see what will happen. It also returns vector of fixed size with 100 values of 0.5 when getRemainingFeatures() is called. This is a brief description, I can provide more code and details if necessary.

3. Results.
   I feed data of 2000 randomly generated values saved in 16k wav-files to my plugin by using either vampyhost or vamp-simple-host

when I run 'vamp-simple-host libtst_plugin:TstPlugin ../tst_noise_16k.wav -o res.txt' , res.txt contains sort of 3 vectors. 2 of size 1024 (I guess that is default block-size for vamp-simple-host) and third vector with 100 vals of 0.5 - all as expected.

when I run vampyhost by using collect, I get result with a vector of only 3 values. First two contain only first values from the processed blocks and last value contains only one 0.5 constant. So it looks like all 3 vectors contain only first values from 3 corresponding vectors from vamp-simple-host case.

4. Question:

a) I do understand that I might be mis-using the VAMP interface and should get sort of undefined-behavior (or implementation-dependent behavior :) ) If so - could some one please tell what am I doing wrong in my plugin?

b) I also understand that 1 line of code might be better then a paragraph on descriptions :) If someone is willing to examine my lousy code - I will gladly provide it.

c) All-in-all - is this a bug or a feature, that I get different results when invoking vamp-hosts that presumably come from same source?

Please give your comments and ask questions.

[cannam]

This isn't a completely straightforward question I'm afraid -- one of the reasons I hesitated over this one for so long (well, that and a period of illness) for which my apologies.

The collect interface in the Python host behaves differently from the straightforward processing carried out by the simple host or by the process interface of the Python host.

The simple host and the Python process interface work by passing each input block to the plugin's process call and then returning, or printing out, the unmodified feature list that it returns. The result should be very close to the structures that your plugin's process and getRemainingFeatures calls actually return.

In contrast, the collect interface attempts to interpret the output's declared properties in order to fit the returned features, if possible, into one of a set of common "shapes". For example, a plugin with a OneSamplePerStep output that is declared as having a fixed bin count of more than one bin per feature will be taken as representing some sort of 2d grid, and will be shaped into a matrix-tagged grid structure.

If collect can't make any particular sense of the output structure, then it will return a list-tagged structure containing essentially the same features as would have been returned using the process API directly.

So some possible reasons for the outcome you describe might be:

• The plugin's metadata (things like the output sample type and bin count for the output) appears to describe an output with a certain structure, but then the actual features returned by that output do not match the structure. In your case, perhaps an output declared with a fixed sample rate and a fixed bin count of 1 might result in collect trying to return the structure you describe. If collect thinks it knows what the structure is supposed to be, on the basis of the plugin's static metadata, then it will try to return that structure even if the actual features turn out not to be consistent with it.

• The plugin's metadata appears to be ambiguous in some way as far as collect is concerned, so that it makes a wrong decision about the output structure.

• The plugin's metadata is sensible but collect either interprets it stupidly (because of a bug in the shape deduction logic) or else interprets it wisely but returns the wrong output anyway (because of a bug in the feature reshaping logic).

A code example, and/or a transcript from the Python Vamp host showing what exactly the output structure looks like, might indeed be helpful in working out what it is that has gone wrong.

[pglushkov]

Hello! Thank you for the reply!
What I did to get the result that I'd expect with 'collect' is setting plugin's sampleType to 'FixedSampleRate'. After that a list was returned and each list element contained a numpy array of expected length and with expected content.
To sum-up - I was wrong to expect collect to function in the same way that vamp-simple-host does and probably erroneous expectations led to all of this. I think this issue is resolved for now.