> On Sat, Mar 25, 2000, 20:06 David Olofson wrote:
>> 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.
>
> Yes, if we're going to use the same ranges for control and signal
> data (which makes a lot of sense), a [-1,1] range is the obvious
> choicel I think. (BTW, "bounded" is not what I want. The range is
> just a recommended standard range.)
On reflection, I think it would be a whole lot easier if signals (be they
control or audio) were just allowed to represent their natural units: I
have a long-term history of fp files with their values stored in Pa - and
this has frequently helped avoid any confusion when re-using data in
different contexts. (I think you are _probably_ saying this by saying you
don't subscribe to bounded anyway).
>> 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.
>
> This is a part of the UI, not the processing plugin API. It doesn't
> affect the processing or the data itself.
Unless we start proliferating gain/scaling controls all over the place.
>
>> 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.
>
> As long as you know what any involved processing plugins are doing,
> there's no problem.
Maybe I misunderstand something here - there have been many steps to the
thread... but it is the issue of how to find this out that I was concerned
about...
In my hypothetical scenario - I might wish to use plug-ins (perhaps
including binary-only $$$ ones). I can't see how the UI can obtain the
information except from the plug-in.
IMHO (for 'studio type' non-calibrated plug-ins) the presence of a whole
flotilla of gain controls at plug-in in/outs is a disaster (this happens
occasionally on VST and is non-intuitive to say the least).
For instrumentation it's a non-starter - unless you provide a mechanism for
the host to retrieve the settings.
Maybe I'm way off track here - but there has to be some coupling between
'how the user sees the plug's behaviour' and 'what the plug's behaviour is'.
Sorry for the ramble,
Iain.
