Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Fri Dec 01 2000 - 19:33:26 EET
David,
I agree that using strings was not the right way to go because it increases
the type-matching time by doing string comparisions.
These days, I would use datype IDs in form of 32bit integers too.
As for the datatype matching functions, in my dynamic -datatype LADSPA
tests , I implemented a way where the host can choose if wanting the highest
or lowest precision match.
eg: assume 2 plugs needs to get connected and both support 32bit and 64bit
floats.
With the highest precision flag, the host would choose 64bit, otherwise 32.
OTOH, if one of the plugs supported only 32bits, both highest precision and
lower precision flags would result in a 32bit connection, since it is the only
possible match. (that's quite obvious :-) )
A third way would be to allow the host to set a preferred datatype anlong the
highest/lowest precision flag. That way if both blugs support the preffered
type, this one will get used, otherwise the matching will fallback
to the highest/lowest precison method.
(any additional useful ideas about matching methods ?)
As for the datytypes:
along the numeric ID, there should be an associated structure which describes
some characteristics of the datatype like size in bits etc (see my
DataTypeDescriptor structure).
That way the host can run plugins even if it does not know how to interpret
the data. (just connect plugins with matching datatypes together, set up buffers
and execute the chain of run() calls)
This will be very handy since it will allow us to run let's say frequency
domain plugins (and other fancy stuff) on simple MAIA hosts.
(eg audioIN --> FFT --> graphical transfer function plugin -> IFFT -->
audioOUT)
Benno.
On Fri, 01 Dec 2000, David Olofson wrote:
> >
> > Plugins are the easy part; the Data Type Descriptors are physically
> > just 32 bit integers (*), and the basic types, such as float32/64,
> ^^^
> Hey! It seems that I forgot to elaborate on this one. :-) So...
>
> The data type management stuff I've speced up so far have been using
> small structs, and now 32 bit integers, for Data Type Descriptors.
> Considering that detailed information on data types (such as FP
> standard, endian, exact bit size etc) isn't of much use unless it's
> evolved into a full-blown IDL style thing, unique IDs might be used
> just as well.
>
> One could use the a string based variant, along the lines of Benno
> Senoner's LADSPA extension, but that's not really safe, uses up space
> in plugins and hosts, and requires the strings to be compared for
> type matching, unless local ID codes are allocated and managed by the
> host. And local IDs would have to be based on what's on the local
> machine, thus not being unique, which could lead to clashes in
> networked environments... Therefore, I dropped both strings and field
> descriptive structs, and decided to use plain, simple 32 bit Data
> Type Descriptors instead.
>
This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 20:58:32 EET