Subject: Re: [linux-audio-dev] more on plugins/LADSPA
From: David Olofson (david_AT_gardena.net)
Date: Fri Mar 17 2000 - 20:18:21 EST
On Thu, 16 Mar 2000, James McCartney wrote:
> > In the big picture, I can't see how multiple, separate APIs can be
> > simpler than a common API that can be used in some slightly different
> > ways. It only makes code reuse harder, makes it a big job to support
> > all APIs in a host, and makes life messier both for the developers
> > and the end users.
>
> Well unfortunately one API can't serve all needs.
True, but that's no reason for intensionally developing multiple
completely incompatible APIs. They all have quite a few similarities,
and there's no real reason why this basic functionality should be
implemented in completely different ways in different APIs.
Or; if there are multiple APIs that share this basic functionality,
implementing it the same way, and then building on that, they are
extensions of the same basic API. As such, they should run in the
same hosts, as long as the specific features of the extensions aren't
required to run the plugins.
> SuperCollider needs real time instantiation,
Capability flag. The rest is not an API issue.
> sample accurate start time,
Capability flag. The rest is not an API issue.
> dual rates on any input (arate & krate),
How does this work? Do inputs have an audio and a control band or
something? For LADSPA, the control rate is the buffer size. Control
and data come through different ports. With the MuCoS event system,
you make the control rate whatever you like - events are timestamped
with sample accuracy.
> variable block sizes per ugen
Supported. LADSPA (unless something has been added since last time I
loooked) requires plugins to accept any buffer size for a run() call.
(BTW, I would suggest that plugins can demand that buffer sizes follow
some rules, like power-of-2 samples or N*X samples. This is to avoid
intermediate buffering when using array instructions (SIMD) or
various normal optimization tricks. Of course, it should be
recommended that plugins use the least restrictive demands possible
without serious performance impact.)
> group. Since these are not supported or guaranteed in this API, so I am
> unable to use it as my ugen API.
I don't see a reason why they *shouldn't* be supported by LADSPA, or
some binary compatible extension to it, unless this impacts the other
uses of the API. I still don't see a technical API conflict here.
> For example in the repatching case you mention in another post, SC unit
> generators do have to know about this, because the calculation rate on one
> of the inputs may have changed and the ugen may want to install a different
> function pointer.
That is, you're using a higher control rate than the plugin function
call rate, so that control data is more like low frequency audio
data...?
If this is the case, the problem with LADSPA is that it basically
supports only two sample rates per plugin; one for the audio data,
and one for the control data. The control rate implicitly equals 1
sample per run() call.
Personally, I think this is way to restrictive for many things, and
I'd like to see an API extension that allows different sample rates
on the ports, requesting of bigger buffers than the actual number of
samples to process in the run() call and some other things. This
extension would not rule out the possibility of writing plugins with
the current LADSPA restrictions - the same low level API can be used,
making single rate plugins a subset of multirate ones.
It's all about reusing what is similar, rather than building
incompatibility in from the ground up.
//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 : Sat Mar 18 2000 - 07:16:44 EST