Subject: Re: [linux-audio-dev] LADSPA Version 1 , supporting an arbitrary number of datatypes
From: David Olofson (david_AT_gardena.net)
Date: Sat Mar 25 2000 - 23:12:50 EET
On Thu, 23 Mar 2000, Benno Senoner wrote:
> 2)
>
> You should add an "unit" field so that the host can use this for displaying
> purposes.
> ie: if the delay is in msec , the unit string should return "ms" or "msec" so
> that the host can display the unit on the slider/knob etc.
Well, I still think the UI should be kept outside the processing part
of plugins. It makes no sense to me having the engine deal with all of
this, when it might not even be used by some plugins... And it can't
be handled in the same thread as the engine anyway, for RT
applications. The information has to be "gatewayed" to wherever the
UI is.
> next
> > 3. runAdding() support is not included. I'm still not 100% sure about
> > this, but I'm a little more sure than previously. It seems that to make
> > runAdding() useful it is necessary to include some kind of setGain()
> > mechanism.
>
> exactly, setGain() and getGain() will be sufficient to allow a flexible and
> efficient adding method.
Still, standardizing on which ports the gain controls would be more
flexible, possibly avoid duplication of functionality, and might save
CPU cycles. Multiplying two control levels is less expensive than
two zipper noise free volume controls inside the plugin. This
optimization could be done by the plugin, of course, in order to
have separate ports for the "normal" gain controls, and the ones
meant for runAdding().
There's one more thing to consider. Does it make sense that all
outputs use the same gain control?
> As for the 64bit FP support issue, I agree with David:
>
> it would be very simple to add a datatype field to the port,
> so that the host can check the type and act accordingly.
>
> the run() , instantiate() etc functions would become a arrays of functions.
> ie: a run() for each datatype
This doesn't work if the data types are per *port*, rather than per
plugin...
[...]
> same for instantiate() and other type dependent functions
With my proposal, you only have to check things before connecting two
ports.
The major difference is that my proposal assumes that a signle plugin
class has fixed types for all ports, ie you cannot instantiate the
same class for different types. Instead, a plugin can handle any
mixture of data types on it's ports, allowing plugins to be
converters, among other things.
Allowing hosts to request different data types per port will result
in a lot of overhead in the plugins, so I don't think that's worth
considering for the API. It can be done by inserting converter
plugins if some plugin should come with a data type mixture that
doesn't follow the logic of the net it's installed in. (Ie, it's up
to developers to "mix" in a sane way, or rather not at all, unless
where it's obviously a logical thing to do.)
[...]
> With this extension , we are not bounded to 32bit or 64bit floats, but can use
> support an arbitrary number of datatypes without breaking binary compatibility
> with 32bit-only hosts/plugins.
Nice.
> If then a complex host will allow the mixing of different plugins, it has to
> do the conversion into the host code.
I don't like that idea. It assumes that all data formats must be
known by the host in order to be supported, which doesn't make much
sense the way I look at the host; as a plugin loader and scheduler.
Per port data typing allows normal plugins to be converters with no
special cases in the host.
> I think LADSPA + the above extension + runAdd() would be really nice , since
> it covers (excluding the event system) almost all our present and future
> plugin API needs. (David , your thoughts ?)
Some details to refine, but this is beginning to look useable. :-)
As for the API itself (the header in particular), the data typing
extension I'm working on is basically just an extension that explains
the low level details of what the basic framework carries. Most of the
code I posted earlier can be ignored by the majority of the plugins,
and all but the data type descriptor type itself can be ignored by
hosts that won't bother with directly touching data.
The event system will be strapped on in a similar fashion, but I'm
not hoping to be able to implement an event system that allows hosts
to support event enabled plugins without any form of host support.
Then again, the only problem I'm seeing is the dynamic allocation
needed for sending events... I'll see if I can sort it out.
> (I am already hearing Richard saying "too complex", but from a plugin developer
> POW I have no big concerns about adding a couple of statements during the init
> phase)
*hehe* I don't blame him. These things tend to add quite a few lines
to the header. Even if most of it is comments describing how to use
the stuff, it's still stuff that the developer has to read and
understand to get things right.
> Notice that with the system above, if a plugin supports multiple datatypes and
> a host uses only one of the datatype, the allocated memory and ressources will
> still be the same as in the float-only case.
> (except for the size of the plugin code, which will be a little bigger since
> some functions ( like run() have to be present for each datatype)
It's pretty obvious that there are two distinct forms of multiple
data type support:
1) A plugin can use multiple data types at once, or any single
data type. The point is that they can use the same API, and
preferably the same hosts, and that plugins can run without
extra overhead as long as only ports of the same type are
connected.
2) A plugin can only handle one data type per instance, but the
API allows more than one data type. Any data type not supported
by the host cannot be used at all in that host. The point is
to avoid restricting plugins and hosts to use a single, hard
coded data type.
> BTW: does support VST2 audio datatypes other than float ?
AFAIK, no.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sun Mar 26 2000 - 00:22:33 EET