Subject: Re: [linux-audio-dev] [ardour] custom graphics + MIDI control for LADSPA plugins
From: David Olofson (david_AT_gardena.net)
Date: Fri Dec 01 2000 - 04:05:35 EET
On Friday 01 December 2000 01:20, David Olofson wrote:
> On Thursday 30 November 2000 15:28, Steve Harris wrote:
> > On Thu, Nov 30, 2000 at 03:50:07AM +0100, David Olofson wrote:
> > > > LADSPA has the advantage, on top of all the obvious ones, of
> > > > existing.
> > >
> > > Yep... However, two usable APIs are better than one broken API.
> >
> > Oh yes, absoloutly, I'm with you all the way that we need an
> > additional, more generic plugin API.
> >
> > > But the main reason why MAIA will support multiple data types
> > > has nothing to do with performance on certain target platforms,
> > > but is actually something that should be obvious by looking at
> > > the name:
> > >
> > > Multimedia Application Integration Architecture
> > > ^^^^^^^^^^
> >
> > OK, *that* is a decent reason, I'l shut up about it now ;), as
> > long as I can write float audio plugins with a minuimum of cruft.
>
> 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.
The first bunch of numbers are reserved for various things like
development/unofficial types and the "built-in" types that every host
must support. (Only native float32 and int32, probably.)
Note: Adding new built-ins after 1.0 will break binary compatibility,
so this should preferably never be done. It shouldn't be
required, so this shouldn't be a problem - the only reason for
treating the built-in types specially is that they're used by
the event system and the Property Protocol, which are
fundamental parts of the API, that every single plugin and host
will have to use.
Then follows a bunch of Optional Types that are predefined in the 1.0
API spec. These should cover most integer, fixpoint and float formats
in all relevant endian formats, as well as some basic packed formats
and other stuff. They are just reserved numbers, so it's no big deal,
really!
Finally, there is a huge range of descriptors that are reserved for
"Extended Data Types"; ie types not defined in the 1.0 API spec. The
Extended Types must still have unique descriptors, so they have to be
managed centrally. (There shouldn't be too many of them needed if the
general design philosophy works, so we hardly even need an official
procedure for registering...)
The only difference between Optional and Extended data types is that
the latter aren't in the 1.0 API specification. It's doubtful that
this distinction has any significance whatsoever, except that it
might come in handy when dealing with API header versions.
It's possible that I'll just have an additional header file for the
Extended data types, and have the 1.0 headers automatically include
that. That way, if you should be missing one of the latest additions,
you only need to update the header with the Extended types, rather
than upgrading to the latest minor version of the API.
The *significant* advantage seems to be that the Optional Data Types
can be kept separate from the basic API, which reflects how things
work on the binary level.
//David
PS. Some of this is most probably going into the MAIA headers,
together with the code. Might be a more comprehensible form, in case
anyone's really trying to understand it. :-)
.- 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 : Fri Dec 01 2000 - 05:38:24 EET