[linux-audio-dev] Additional LADSPA hints

[robbins jacob]

To my own surprise I have to object to the suggestion:
/*
AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled 
by a high time res. slider or control data, but shouldn't be connected to 
the next audio signal by default. I can't think of any simple examples off 
hand, but combined with MOMENTARY it could be used for sample accurate tempo 
tapping.
*/

As is see it, this declares that an audio port should be used for control 
data. I oppose because it is ugly to declare a port one thing in its 
PortDescriptor only to reverse this in the PortRangeHint. Furthermore, this 
ugliness is likely to cause problems in hosts that do not parse this hint 
value*. I believe that the true intention here was to undo the requirement 
that data ports can only have one value per run() block, but the author 
realized that undoing that requirement has significant implications. The 
primary problem occurs when the plugin assumes a particular control is 
continuous but the host abides by ladspa.h v1.1 which does not allow more 
than one control value per block. The plugin will treat that control port's 
data pointer as if it pointed to an array of the blocksize passed to run(), 
but the host will have only allocated a single value so there is a memory 
error.

(*)I argue that turning audio ports into data ports will cause enough host 
incompatibility problems that you might as well do it correctly IF you 
really feel it's worth it to add this feature. Here are some 
incompatibilities which arise from using audio ports as continuous control 
ports:
-the host doesn't parse the hint and sends audio to the control resulting in 
caucophonous output.
-the host does realize it shouldn't send audio to the "audio" port but 
doesn't have a facility for sending control data arrays to audio ports, so 
the user is unable to manipulate some of the controls on the plugin. Plugin 
writers are more likely to use continuous controls for important plugin 
features which warrant the extra detail, so unmodified hosts will be unable 
to accomodate very useful plugins that do who-knows-what.

  Basically, introducing arrays of control data will force ALL reasonable 
hosts to adapt to handle that ability. So I believe we are better off 
keeping ladspa.h straightforward and self consistent by eliminating the 
strict single control value requirement and dealing with the issues 
involved, as opposed to maintaining a false veneer of backwards 
compatibility by allowing use of audio ports for control data.

  What are the issues involved with eliminating one control value per block? 
I think that all you need to do is remove it and add a data port hint 
CONTINUOUS which means the host _must_ attach that control port to a whole 
block's worth of data for each run. As i said before, this kills backwards 
compatibility of hosts, but you are going to do that for the majority of 
hosts anyway if you reappropriate audio ports for control data and 
reappropriating audio ports is ugly.

As to whether I support adding CONTINUOUS data ports and breaking host 
compatibility; i haven't written my host yet so yes i support it because it 
will be easy enough to implement (or so i think :)


--jacob robbins.................






_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail