Paul Davis wrote:
>You've apparently never used an analog modular synthesizer :)
>
Nay, I have used analog modular synth and I know what you're talking about.
>LADSPA is the same. If the plugin declares a port to accept audio, it
>can use the input in any way it wants.
>
No it doesn't work this way. A port is declared by the plugin, and the
plugin knows which ports (even if it's an audio port) it uses as control
ports. But when a host sees a port that says LADSPA_PORT_AUDIO, it
doesn't know that is a control port, so think about what happens in the
UI level. In a typical "network UI" view, the audio port shows up as one
of the audio pins, and the user has no way to tell which pins are the
actual audio ports, and which pins are the control ports disguised as an
audio port. Nothing gets more misleading than this.
>We know that the current way of declaring control ports
>doesn't make it clear that they are all connected to the same
>fundamental parameter, which means that any automatically-built,
>host-suppled UI will be misleading and perhaps even unusable.
>
The issue is not the difficulty to show connection of different control
ports. And even so, the automatically built UI won't be so misleading
either. Let's take the example of an equalizer plugin. We can let the
plugin take several control ports, each specifying the gain at a
specific frequency. Say we have 32 of them. On the UI, it is very easy
to show there are 32 gain "sliders" in the dialog box if all of them are
label properly, and it is not misleading at all. Now, think about what
if I want to equalize in a finer band than those defined in the control
ports? Do I add more fixed control ports, or do I simply use an array
structure to specify the pairs in the form of { freq0, gain0, freq1,
gain1, freq2, gain2 ... }? Which one is more elegant?
And back to the previous audio-port-as-well-as-control-port issue,
nothing gets more misleading than that. If misleading UI is an issue for
you at all, then you contradict yourself by proposing the dangerous use
of audio port as control port.
>But your
>suggestion doesn't seem to me to address that, and doesn't provide
>anything more than the ability we have now to declare a bunch of
>control ports, and use them inside the plugin in some "unorthodox" way.
>
Well, I as well pointed out the drawbacks of those unorthodox hacks. It
is really up to you or any other person to decide whether those
drawbacks are significant enough to hamper the well being of ladspa and
applications that use it. I can't seek to argue more if you so earnestly
believe there is no need to change ladspa, and you want to defend this
belief at all cost.
liulk
