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: David Olofson (david_AT_gardena.net)
Date: Sun Mar 26 2000 - 06:28:20 EEST


On Sun, 26 Mar 2000, Iain Sandoe wrote:
> > 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).

It's important to note that the octual values and their
representation in a GUI are two different things. The port
description file I'd like to have instead of the LADSPA_HINT stuff
is what explains how to do the conversion when needed.

The data passed around between plugins should be kept somewhere near
the standard range in order to reduce the number of conversions.
Obviously, this makes sense only for modular synthesizers and the
like - not for instrumentation and control prototyping tools.

So, yes, if the standard range only causes trouble for your plugins,
ignore it! If some musician finds that they have interesting effects
on audio signals as well, he can still use them, even if he might
need to use some gain + DC offset plugins to adapt them to the
standard range used by most audio plugins.

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

Well, that's what I want to avoid. They stress the cache optimization
and bring extra overhead, so they should only be used when
explicitly desired. Having the low level API support all kinds of
ranges has the exact opposite effect, as it implicates that hosts
adapt ports to each other one way or another. (And as for "adapt", I
can't see what a host should do when connecting ports with unrelated
units. Still, this will happen all the time in audio systems, as
soon as you start using control ports.)

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

The port description file that comes with the plugin it where I'd
look for it, unless I'm just using the custom GUI that may have been
provided as well.

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

You wouldn't want to use that kind of plugins for processing
measured data before display, I think. You *could*, but you'd better
make sure you know what happens inside it first... Audio plugins are
tuned to *sound* good, not to be accurate in the instrumentation kind
of sense.

> For instrumentation it's a non-starter - unless you provide a mechanism for
> the host to retrieve the settings.

As long as the control ports affect the signals (or control outputs -
plugins don't need to have any signal ports at all) in a well defined
way, you need only the info in the description file, or built into
tho custom GUI module. If the plugin does *not* behave in a well
defined way, it probably has too much analog feel to be usable in
instrumentation anyway. ;-)

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

What the signal and control ranges mean should be defined in this
description file I'm raving about all the time. As for what the
plugin actually does with the data, that's defined by the code, and
the user interface description of that should come in the form of the
name of the plugin and it's ports.

I don't think this is off track, as it has to has to be sorted out
properly in order to avoid crippling the API for no technical reason.
For audio, you can get away with lots of shortcuts and vague
definitions of behaviour, but this is not the case for other kinds of
signal processing.

//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 -'


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

This archive was generated by hypermail 2b28 : Sun Mar 26 2000 - 07:48:34 EEST