Subject: [linux-audio-dev] Additional LADSPA hints
From: robbins jacob (jacobrobbins__AT_hotmail.com)
Date: Fri Jan 17 2003 - 20:28:44 EET
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
This archive was generated by hypermail 2b28 : Fri Jan 17 2003 - 20:29:34 EET