Re: [linux-audio-dev] New LADSPA Version - Issues Resolved?

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

Subject: Re: [linux-audio-dev] New LADSPA Version - Issues Resolved?
From: David Olofson (david_AT_gardena.net)
Date: to maalis 09 2000 - 20:23:45 EST


On Thu, 09 Mar 2000, Alexander König wrote:
> Hi,
>
> "Richard W.E. Furse" wrote:
> > New version of the LADSPA API and example plugins/hosts available at
> > http://www.muse.demon.co.uk/ladspa.html. Plugins-per-library issues are
> <..>
>
> Hey, this looks really good! Now I have a question regarding control
> ports (I haven't read all the plugin discussion posts so I can just hope
> I'm not annoying everybody with a FAQ). From looking at your source it
> looks like the only place where a plugin lets the host know the value
> range for a control port is the PortNames string. Now if the host wanted
> to provide for example a GUI for the LADSPA plugin, it would have to
> parse that string to find out about the ports value range? If so, why
> not provide something like
>
> float * PortValueMax;
> float * PortValueMin;
>
> and maybe even a
>
> float * PortValueDefault;
>
> with a useful default value for each control port? Oh and if the port is
> a simple toggle-value (that turns something on/off within the plugin
> (value=0.0 -> off, value > 0.0 -> on)) how about a
>
> int * PortIsToggleValue;
>
> so that a GUI could provide a button instead of range widget?

I'm not sure this is the right way to do it... I'm beginning to like
the VST way (min is always 0.0, max is always 1.0), since it makes it
very easy for the host to connect plugin control ports. The same
issue exists for the MuCoS events, and I'm considering the same
solution there.

Now, OTOH, this design forces the controller <-> actual range
convertion on the plugins, which isn't compatible with my idea of
keeping plugins as simple as possible. (There will be enough
complexity anyway, as there is no such thing as "too simple".)

Then again, in the MuCoS event system, the host usually won't even
touch the events! It just connects plugins and lets them do the job,
just as with audio (and other streamed) data. That suggests that the
fixed range/conversion inside plugins design is the way to go...

Smooth middle way? Other ideas?

(As a result of this public reflections of mine, my current opinion is
that a fixed controller range does have more pros than cons... Now,
if we involve integer controller values, things are all different,
again! :-)

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


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

This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST