[linux-audio-dev] Additional LADSPA hints

[Mike Rawes]

On Fri, 17 Jan 2003 10:28:44 -0800
"robbins jacob" <jacobrobbins_ at hotmail.com> wrote:

> 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. 

Yes. At present, ladspa allows two types of port:

LADSPA_PORT_CONTROL (one value per block)
LADSPA_PORT_AUDIO   (array of values per block)

However, some plugin authors (myself included) wanted finer control over
the parameters, so we 'overloaded' the AUDIO port to allow per-sample
control data. This has been used in many libraries: cmt, swh-plugins,
blop, and it works fine in hosts that allow direct wiring:
SpiralSynthModular, AlsaModularSynth, gAlan.

However, other hosts such as Ardour and Ecasound do not have the same
direct wiring functions, and instead treat any AUDIO ports as exactly
that (making them available as Effect Sends or similar). The purpose of
the new hint is to accommodate these hosts:

LADSPA_PORT_CONTROL            (one value per block for control data)
LADSPA_PORT_AUDIO              (array of values per block for audio
data)
LADSPA_PORT_CONTINUOUS_CONTROL (array of values per block for control
data)

Hinting a port with this new hint would allow such a host to treat these
ports as per-sample controls, and not audio ports, and perform the right
actions. It would require existing plugin libraries to change their
hints.

> 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*.

PortRangeHints, if given, only specify minima and maxima for an input
port, and are semantically the same for both port types. Can you
elaborate on this?

> 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.

The host should allocate a single value for ports hinted as
LADSPA_PORT_CONTROL, and allocate an array of sample_count for those
hinted as LADSPA_PORT_AUDIO, as per ladspa.h. For ports hinted with the
new hint, an array of sample_count should be allocated.

> (*)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.

This is what we want to avoid. It is only a problem for hosts that
automatically insert plugins into an audio stream. To do this, we need
to make a distinction between AUDIO ports, and per-sample CONTROL ports
and only use AUDIO ports for audio data. This is what the new hint would
deliver.

>   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.

I agree. But sometimes, per-sample control isn't needed and/or wanted
(due to seldom changing values, cpu usage and so on). So I think having
three hints is still needed.

>   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.

Again, agreed. We want to remove the 'overloading' of AUDIO ports for
control data. I disagree with removing per-block ports, though.

Mike
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com