Subject: Re: [linux-audio-dev] LADSPA GUI Issues
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Fri Mar 31 2000 - 02:08:05 EEST
Kai Vehmanen wrote:
>
> On Thu, 30 Mar 2000, David Olofson wrote:
>
> >>> 1) How do hosts convert data when needed? (That is, if not
> >> They don't. This is why we have just a few format (32bit and 64bit
> >> float). You recompile, load another .so file, contact the plugin
> > Ok; maybe I've had to deal with too much closed source/proprietary
> > crap before I started to use a real OS, but this attitude worries me
>
> Hmm, here's my thoughts in a nutshell:
>
> - converting from format to another format is expensive
> - it's very likely that either the host or the plugin
> is open-source (recompiling one of them is enough)
!!! recompiling as a way to get flexibility is WRONG. completely
wrong. and not possible in all cases.
rationale:
if you want to use one plugin that's just 8 bit and produces e.g. blue
dots on the screen based on the low frequency amplitude (this might
serve as kind of metronome or something) [8 bit signal for that might be
plenty enough and let's say it's binary only plugin] you will do all
your sound processing in 8 bits???
also: some processing might by its nature require different formats.
the data conversion should be done at host because the host knows if
it's necessary (say you are connecting 32 bit -> 32 bit -> 8 bit -> 8
bit host does only one conversion, but if the plugins were responsible
for converting to standard you would have at least four conversions
(from/to two 8 bits or from/to 32 bits)).
also, if you have binary only plugin that's uses 32 bit data and
binary only that uses 64 bit data how exactly do you recompile that host
so that it can use both?
data conversions should be avoided (they are usually not necessary and
are expensive) but not banned.
more general rationale:
you cannot recompile binary only plugins (I think they should be
allowed)
if you change the size of data element some algorithms might not work
(as was already mentioned in this discussion)
it gives you 'horizontal' flexibility - everything is same but you can
change it over time instead of dynamic flexibility - usign different
things at one given time
> - if we want to support multiple formats, avoid conversions
> and avoid recompiling, either the host or the plugin will
> have to support multiple formats
(IMO) obviously host has to support conversion between formats. I have
already posted reasons in previous post, also see above.
> - we'd like to see lots of LASDSPA hosts and plugins
> (most linux audio apps should be able to host LADSPA
> plugins)
> ==> complexity is something we should avoid, even if this
> forces us to some compromises
there is no (or VERY little) complexity added to plugins. but lot of
flexibility.
regarding data types: it is (hopefully) possible to describe them by
parameters, so that the host does not have to have specifically coded
conversion from each type to each another type but simply have algorithm
that 'understands' the data format description. host should not do any
(other) DSP (IMO) so it does not have to understand what the data
actually mean.
something along the lines (just an idea, not a real proposal):
typedef {
int id; /* or char *name */
int size;
int scale; /* enum { linear, logarithmic, ... } */
int encoding; /* enum { none, mp3, ... } */
} Datatype;
scale and encoding might be just one thing... but the encoding might
not be necessary because it's data semantics that I just said does not
interest host (but it might interest other plugins)...
for simplicity of plugins there might be some macros or wrapper
functions defined... you have to have something like that anyway since
you never know what is the actual size of int or long or whatever.
to design such a system is non-trivial (even hard:-) but to use it
from the plugin side would be almost the same as using one-type-fits-all
solution. the host would have to take care of formats but it still would
be fairly elegant (=simple/efficient/understandable).
I guess this is not a suggestion for LADSPA 1:-)
erik
This archive was generated by hypermail 2b28 : Fri Mar 31 2000 - 03:14:29 EEST