Re: [linux-audio-dev] Additional LADSPA hints

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Additional LADSPA hints
From: robbins jacob (jacobrobbins_@hotmail.com)
Date: Wed Jan 22 2003 - 09:02:08 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.

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

This is what I'm getting at: the original suggestion was to introduce a
LADSPA_HINT for continuous control which would be applied to ports of type
LADSPA_PORT_AUDIO. I think that this is misleading because I interpret port
type = audio to mean that the port is for audio content as opposed to
control content. I agree with the proposal as you present it here, adding a
new port type (not a new hint).

However, it seems that plugin writers are more comfortable interpreting port
type=audio to mean that the rate of the port is audio rate. Steve suggests
that it is splitting hairs to try to absolutely determine whether an
audio-rate port is for audio or control content. If this is the case then we
should just leave 2 port types and add a hint for audio-rate ports that they
should be used for control data.

I feel I must warn that this will make the ladspa_port_types audio vs
control a little misleading to people when they first read the header. If
the port type is chosen to be audio and not data then the port should be for
audio and not data, right? In short I think adding a third port type would
keep the header self-consistent, whereas adding a hint that overrides and
reverses the port type is twisting the standard to match current useage.

--jacob robbins.....

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jan 22 2003 - 09:05:20 EET