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)
data)LADSPA_PORT_CONTINUOUS_CONTROL (array of values per block for control
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
