> 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.
>
I've been (kinda) following this thread.
I have two requests:
1/ If the range is to be bounded could it be signed please (this appears to
me to be a more natural representation) - and the sign bit is 'for free' in
fp.
2/ It must be possible for scientific (e.g. instrumentation type apps) to
know explicitly what the signal range refers to in some absolute units.
For example, I may well have calibrated microphones/converters and I *will*
want to know what the NSD of the signal is in Pa/root Hz.
So, it doesn't matter too much how it is implemented (the arguments for and
against the different methods all appear to have both merits and demerits) -
so long as, at the end of the day, it is possible to extract the calibration
of the system one end to the other.
Iain.
