Re: [linux-audio-dev] LADSPA GUI Issues

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

Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Wed Mar 22 2000 - 16:11:54 EET

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.
2. Plugins can optionally use capability-flags to describe
   the ranges it uses (both data and control).
3. Actual data type (32/64/128bit float) is determined at compile
   time. It's easy to recompile OS-plugins (or release multiple
   binary versions).

All in all, this leaves more responsibility to the end-user, but that's
not necessarily a bad thing. For instance, if a plugin causes problems in
a realtime-environment (realtime instantation), user just won't use it.
It's that easy. Hmm, we could use a standard plugin-data-sheet for
documenting all plugins (==> the end-user can check the facts). The
API-spec guarantees that all plugin/host combinations will work on a
technical level. 

--

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.
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.

--

There has been strong arguments against forced sample value ranges
(bit-to-bit accuracy, efficiency by avoiding scaling of sample value
16bit->float->16bit). I see no reason, why we should use a different
policy for control values.

-- 
Kai Vehmanen <kaiv_AT_wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux multitrack audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

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

This archive was generated by hypermail 2b28 : Wed Mar 22 2000 - 13:57:36 EET