Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: David Olofson (david_AT_gardena.net)
Date: Sat Mar 25 2000 - 21:45:11 EET
On Wed, 22 Mar 2000, Kai Vehmanen wrote:
> On Tue, 21 Mar 2000, David Olofson wrote:
>
> > * Plugins define range for every port
> > * Hosts get to scale everything
> > * Plugins should check their input to avoid crashes
> [vs]
> > * "Normal" range of [0,1]
> > * Other values allowed
> > * Limiting/checking done by plugins
>
> Hmm, what if we added a "uses normal range" capability? I'm starting
> to lean towards a more "open" approach.
>
> 1. API doesn't specify any constant value limits for sample and
> control values.
Ok...
> 2. Plugins can optionally use capability-flags to describe
> the ranges it uses (both data and control).
Who will use this feature if it's optional? Why specify it, and who
would read it?
> 3. Actual data type (32/64/128bit float) is determined at compile
> time. It's easy to recompile OS-plugins
Ok, but how do you keep track off all different versions of
everything? (Some hosts may not be OS, you may not want to bother
with sources at all, etc...)
> (or release multiple
> binary versions).
I don't think this will happen unless it's *required* that all
ormats are supported.
> All in all, this leaves more responsibility to the end-user, but that's
> not necessarily a bad thing.
It's problematic enough as it is with Linux base systems and end
users. *Control* is a good thing, but responsibility in itself is just
the price you may have to pay to get control. Why pay more than you
have to?
> For instance, if a plugin causes problems in
> a realtime-environment (realtime instantation), user just won't use it.
> It's that easy.
Not good enough. If a plugin doesn't explicitly say that they can do
real time instantiation, I'd never put it in an end-user system that
needs it. Testing is useless, as it doesn't guarantee anything - you
may just be "lucky" with the test system.
> Hmm, we could use a standard plugin-data-sheet for
> documenting all plugins (==> the end-user can check the facts).
A separate source of unreliable information? I don't think so...
Would be cool as a quick reference when looking for new plugins, but
nothing else.
> The
> API-spec guarantees that all plugin/host combinations will work on a
> technical level.
"Technical level" does, by all means, include that the plugins should
*work* together with hosts that require certain features. If they
don't, at least the host should be able to tell the user that this
setup is probably going to suck.
Keep in mind that for some applications, failing a single deadline is
as serious as a kernel crasch. No room for guessing.
> Dropping capability flags (concerning data and control values)
> altogether from the API... well, that would be bad. Here's
> a few examples:
>
> 1. OSS-output plugin. I wasn't very enthusiastic about this, but
> let's say someone wants to write one. Plugin and host side
> must exchange info about the used sample value range, one
> way or another.
What is that info useful for? If the data format isn't reflected by a
standard format, someone will have to adjust the level or compress
the data anyway. Doing it in an external plugin means only that the
host has to keep track of it, and that there will be extra overhead.
> 2. Dynamics processors (compressor, limitter, etc.), waveshapers, etc.
> The end-user can of course adjust the signal level and thresholds
> values, but for a complex plugin, this is rather cumbersome.
This problem doesn't exist if there is a standard range. Plugins are
expected to conform to this standard range, rather than the host
throwing in extra gain plugins all over the place; that's the whole
point.
Now, if a plugin for some reason uses a non-standard normal range,
this is going to confuse the user, but that's pretty normal for
broken code.
//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 25 2000 - 22:19:17 EET