Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)
From: Richard Bown (bownie_AT_bownie.com)
Date: Wed Sep 04 2002 - 16:35:01 EEST


On Wednesday 04 September 2002 13:28, Tim Goetze wrote:

> >Isn't this where the audio servers such as aRts have hoped to do
> >business too?
>
> i don't know much about aRts, but from what i have heard it isn't
> 100% clean realtime, and it's based on a particular programming
> toolkit that not everybody wants to link against.

aRts is a bit schizophrenic - it wants to be a multimedia framework for
thin "player" clients as well providing low latency audio and MIDI for
sequencers as well as being a central repository for plugins. Recent
discussions to address the basic conflicts of interest have highlighted
the problems and are seeking to address them but I don't think it's
going to be happening any time soon - and whatever it is it's not going
to be a single solution/process anymore.

> paul d is known to be fond enough of code reuse to not invent the
> wheel twice, and we have both jackd and aRts. i take this to support
> my conclusions.

No I quite agree. I was just drawing a comparison because while to a
certain extent implementing plugins at the server for aRts was a boon
to thin client multimedia apps this came at the expense of applications
that wanted a little more control (such as sequencers). I didn't want
to see history repeating itself but then again I was already pretty
sure that it wouldn't.

[JACK and plugins]

> of course this needn't strictly be integrated with jack. otoh,
> combining it with a system-wide timebase opens up another dimension.

Ok, this is kind of what I was getting at. So in effect what we could
do right now is simply come up with our plugin abstraction layer
straight away without waiting for JACK to implement anything else?
Whilst the implementation of where plugins sit is something for
tomorrow - today we can say _this_ defines our plugin interface and
create (toolkit specific) libraries that understand this abstraction
and implement them for qt or gtkmm etc.

Indeed for the moment this is kind of what I've done for RG - I've just
created a wrapper for LADSPA that's essentially just got the types
abstracted (typedef float PortType) and encapsulated in hierarchy and
that sits over LADSPA and talks abstract plugin language to the main
gui. As this would be part of the exercise outlined in the above
paragraph anyway perhaps it's worth implementing a LADPAL (Plugin
Abstraction Layer) and its toolkit equivalent libraries now anyway?

Or did I miss something important? I probably did.

B


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Sep 04 2002 - 16:46:41 EEST