Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: David Olofson (david_AT_gardena.net)
Date: Sat Dec 02 2000 - 06:50:38 EET
On Friday 01 December 2000 18:33, Benno Senoner wrote:
> 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 ?)
The third method makes most sense to me, as it basically means that
you as a user decide on what "system wide" data type you want to use.
However, it might be because I'm tired, but I'm not really seeing how
the highest/lowest system fits in there... The host will just try to
get the preferred versions of all plugins, and whenever the desired
version don't exist, it'l have to use another version + some
converters.
Now, in a scenario where we're dealing with a whole bunch of
different formats (16 and 32 bit int plugins for game engines, 32 bit
float for audio, 64 bit float for data aquisition/instrumentation
etc), it might make sense to define a method for the host to
prioritize data types according to user preference.
Very simple approach: The user gives the host a list of data types in
order of preference. When the host is to throw in a plugin, it just
scans the list until it finds a data type for which there is a
version of the plugin.
As to plugins with multiple data types (data types are specified per
channel for Properties and per port for streams and buffer ports),
when a connection is to be make, just throw in a converter if
required. The above rules have already picked the most suitable
plugin versions out, so that's all there is to it.
> 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).
I have a very similar thing in MuCoS 0.0.6 (not in the released
tarball, though, IIRC), but I dropped it for MAIA 0.0.7. (Most of it
at least; see below.)
Why? First, it has to be very complex to be useful (subset of IDL,
more or less) and second, who would use it anyway? If you want to
know more about a MAIA datatype, you should consult some suitable
tool or API extension; *not* the base API. The only places where you
really need this information is in converters, and unless you're
writing a totally generic converter, the information will be
hardcoded in anyway.
> 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)
The size of one element is about all the host has to know. I'm
thinking about simply encoding it into the Data Type IDs... There are
about 16 bits we could use for that.
Why? Just because I don't want to throw extra structures and stuff
into the base API spec, unless it's really needed. There will be
enough of that stuff anyway, so how about just;
typedef maia_ui32_t maia_typeid_t;
then have a few macros to build IDs nicely, only for the MAIA
headers, and then a macro to extract the element size;
#define MAIA_TYPE_SIZE(x) ((x) >> 16)
or something?
In case you're interested, the lower 16 bits are currently encoded so
that there are a few "classes" of types; currently
#define MAIA_TYPE_SPECIAL_ 0
#define MAIA_TYPE_PROTOTYPING_ 1024
#define MAIA_TYPE_STADARD_ 2048
#define MAIA_TYPE_EXTENDED_ 8192
#define MAIA_TYPE_LAST_ 8192
Then we have
/*
* Endian modifiers.
*
* Apply to the Optional and Extended types,
* but should NOT be used with 8 bit types.
*/
#define MAIA_TYPE_BE 0
#define MAIA_TYPE_LE 256
(What is that PDP-11 (or where it was used) thing called? More than 4
kinds needed?)
And then the optional range, which is split into some subranges;
/*
* Sub-ranges inside the optional range of IDs
* (Encoding is based on blocks of 1024 numbers,
* split in 4 parts of 256 numbers. The parts
* determines the endian.)
*/
#define MAIA_TYPE_STD_I_ (MAIA_TYPE_STD_)
#define MAIA_TYPE_STD_F_ (MAIA_TYPE_STD_ + 1024)
#define MAIA_TYPE_STD_FIX_ (MAIA_TYPE_STD_ + 2048)
#define MAIA_TYPE_STD_GFX_ (MAIA_TYPE_STD_ + 3072)
#define MAIA_TYPE_STD_MISC_ (MAIA_TYPE_STD_ + 7168)
Finally follows lots of normal and weird types in the above
cathegories, although without endian info, which is added using the
endian modifiers.
Anyway, as a plugin hacker, you don't have to worry about endian: Not
specifying any endian modifier will give you the Data Type ID for the
native format on the platform you're compiling for. (I might
rearrange the header a bit to do that even without an extra set of
constants.)
> 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)
Yes... If frequency domain data is actually a data type.
As it seems now, MAIA will deal with that kind of formats on a higher
level, which means that such data is just buffers of MAIA_TYPE_F32
(or whatever you want to use), rather than something abstract that
only a specific converter, or plugins with direct support, can
understand.
This is a result of the design decision that flexibility on the end
user level is high priority. You have to stay away from using
countless "data types" hidden behind opaque data type IDs if you're
supposed to be able to connect things in any other ways than the
developers explicitly thought of.
For example, why not tap single bands from the frequency domain data,
and send the data to various control inputs (Properties)?
So, how does MAIA match connections then, if you can't tell frequency
domain data from audio data by looking at the Data Type ID!?
Simple: The size and timing characteristics of things like frequency
domain data buffers are not compatible with those of audio streams,
which means that different protocols are required. Translating
accross protocols *is* still possible, but for obvious reasons, it
can't be done on the very low level that we're talking about when
dealing with ID matching on ports using the Buffer protocol. (LADSPA
style audio ports, that is.)
"Ok, so frequency domain data is something that's communicated as
arrays of some MAIA_TYPE_xxxx, every now and then, as defined by the
streaming port parameters... What if someone tries to pump frequency
domain data into the wavetable buffer input of an oscillator?"
Well, it will sound strange (looping waveform that is actually a
frequency spectra), but what's the big deal? The ports are physically
compatible, so nothing Bad will happen. Perhaps it'll even produce a
usable effect...
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sat Dec 02 2000 - 08:35:16 EET