Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: David Olofson (david_AT_gardena.net)
Date: Fri Mar 17 2000 - 23:19:10 EST
On Fri, 17 Mar 2000, Kai Vehmanen wrote:
> On Thu, 16 Mar 2000, David Olofson wrote:
>
> [ static control value ranges ]
> >> a filter plugin, I want to specify the cutoff-freq using Hz
> >> (eg. 400Hz). You can always use the range recommendation to
> > My idea is that no scaling should be done in the middle of the
> > processing (ie inside the net or engine), as this is just overhead to
> > work around something that doesn't make sense on that level anyway. I
>
> I disagree here. For example in ecasound, all control sources
> (oscillators, MIDI-CCs, input-widgets) produce float values between
> [0,1]. All scaling is done in a separate object ([0,1] -> [n,m]).
> Effects, on the other hand, don't do any scaling. Thus scaling is
> only needed when fething new values from control sources.
That is, *everywhere* in something like a modular synthesizer, or a
virtual mixer with automation. With some consistency in the
controller ranges, scaling will only be needed occasionally, and
never when connecting ports that are intended to be connected, unless
the user explicitly wants to do scaling.
> Another problem is parameters with a theoretical value range of
> (inf,inf). For instance, how does an amplifier-plugin interpret
> the [0,1] value range?
This is not a problem. My original idea was that the ranges would
have to be *fixed* to the standard range, but this is not the case.
The standard range is only the recommended "normal" min and max -
just to make all inputs behave in a somewhat consistent way without
active intervention from the host.
> But, but, if we still decide to use [0,1], then we need to
> add new function hooks to the API... 'real parameter value' ->
> 'control value' and the other way around. Otherwise it's impossible
> to generate a usable GUI for LADSPA plugins.
This is putting UI stuff in the processing part of the plugins, which
IMO, is plain wrong for a generic plugin API. This info belongs where
the UI is. That is, either in the custom UI plugin/module/program for
the plugin, or a config file describing the plugin.
Not only is this information of no interest to the engine part of the
host (and possibly even to the host altogether) - there may be more
than one way to represent the range. For example, I'd like to be able
to specify delay times in samples, seconds, milliseconds, centimetres
of sound travel in air and inces of air travel in air. How to map
the 0.0 - 1.0 range correctly? Scale it *again* in the UI? If so,
what about the standard UI that the host can build from the info
returned from the calls you suggested?
I don't think there is such a thing as a correct range or unit for
most data. European or US standards, for starters? Considering this,
I think it's a *very* non-Free/Open idea to hardcode it into the
plugins, removing the ability for people to change it. Put it in an
external file, and the end user can tweak the UI even for closed
source plugins. And the host's processing engine need not bother with
it at all, not even when the user is changing the net routing.
//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 -'
This archive was generated by hypermail 2b28 : Sat Mar 18 2000 - 07:03:25 EST