Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Thu Nov 30 2000 - 16:13:22 EET
On Thu, Nov 30, 2000 at 04:43:24AM +0100, David Olofson wrote:
> Audio ports have Data Type Descriptors, that hosts have to match when
> making connections. Converter plugins, libraries or inline code can
> be used to convert data if needed.
I've allready made my feelings clear on this point, and no-one has yet
given a good reason for it.
> I'm thinking about allowing plugins to use these for some kinds of
> dynamic allocation. The event pool can actually be used that way
> right now - call it a bonus feature...
If the event pool is in 32byte chunks it wouldn't be fast enough for use
in a lot of plugins, you really need big lumps of contiguous RAM for
wavetables and stuff.
> > - data ranges - currently both control data and audio data
> > are not normalized to any specific range"
>
> This can't really be done in any useful way with audio plugins. The
> most sensible thing along these lines I can think of is dynamic
> integer formats. That is, basically FP formats where an entire buffer
> shares a single "exponent" field. That's a nightmare to work with,
> and doesn't belong inside DSP nets.
Buts thats what DSP programmers spend a lot of time doing, ensuring that
an array of floats shares the same exponent allows you to shortcut
table lookups, for example.
> *What* do people actually want with this? I've still not seen any
> sensible mathematical or other explanation why one would want a
> normalized range. To me, it looks like "math utopia", but I might
> still be missing the point...
A fair number of audio techniques *need* bounded range input. Of the top
of my head: ringmodulation, waveshaping, distortion, click removal,
dynamics processing and transient processing.
> MAIA will simply define a "recommended 0 dB level" for signal data
> types, so that audio plugin writers will have some idea about what to
> expect.
This would probably be enough, but ideally the hosts should be required
to conform to it (obviously other plugins might junk the data, but thats
another problem). Floats bounded to (-1,+1) are ideal, as that is what
95% of DSP routines are designed with.
> > As far as I remember, only one serious problem came up. James
> > McCartney reported that his SuperCollider software absolutely
> > requires 3 (plugin instantation must be rt-safe).
>
> This is part a plugin implementation issue, part an API issue. The
> host may have to provide RT memory management, plugins need to be
> deterministic WRT instantiation time/CPU usage, and plugins have to
> tell the host about it for any of this to make any sense without
> forcing *all* plugins to be RT instantiation capable.
Why shouldn't plugins all be RT instantiation capable? Usually all they
need is an RT safe way of allocating memory. All my plugins would be RT
safe in instantiation execpt that I have to call malloc a lot.
> Right; I don't see how the above can be incorporated into LADSPA
> without giving it the VST 2.0 syndrome (multiple interfaces with
> overlapping functionality), and I don't see how anything with a
> sample accurate event system can be as simple and efficient as LADSPA.
Actually, with sample accurate events, you could write some really
efficient stuff, one of the main speed problems with LADSPA is the
tradeoff between detecting parameter changes and recalculating tables
etc. for every chunk.
- Steve
This archive was generated by hypermail 2b28 : Thu Nov 30 2000 - 17:09:19 EET