Subject: Re: LADPA (was Re: [linux-audio-dev] emagic (logic) drops VST support under OS X)
From: Tim Goetze (tim_AT_quitte.de)
Date: Wed Sep 04 2002 - 15:28:42 EEST
Richard Bown wrote:
>On Wednesday 04 September 2002 11:33, Tim Goetze wrote:
>
>> what i am trying to steer towards is an approximation of 'plugins'
>> and 'applications'.
>
>approximation == abstraction?
yes, making them look the same. with 'applications' possibly being
broken down into many 'plugins' to provide their functionality on
a finer grain.
>> if both interface with the same system-wide
>> graph in the same way we get possibilities for free that must be
>> coded over and over again with the 'monolithic' application
>> designs we currently have. (by which i also mean .so-based designs
>> that force you to do source/header reading and coding before
>> connecting.)
>
>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.
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.
>I'm currently trying to code plugin abstractions as part of a LADSPA
>host for Rosegarden and sure enough when I compare what I've come up
>with against the code for ardour or MuSE I can see that I am just
>basically rehashing old ground.
>
>I would like to make a point further to this but I think I'm getting the
>out-of-process argument mixed up with the where-should-the-gui-go
>argument. I can see that these two _can_ be related but they don't
>have to be. Also I'm getting more confused by the RDF stuff. I was
>under the impression that it was going to be a grammar for describing
>plugins and therefore I hoped something to extend LADSPA hints somewhat
>perhaps/help with gui building.. it seems I was a bit out there.
>
>Any simple explanations for a simple person?
all explanations i can offer come from a simple person.
the out-of-process dilemma exists primarily because our toolkits
don't work together within one process. another reason may be that
most (if not all) of our powerful applications are designed to run
as a separate process.
jackd allows these processes to interconnect via a realtime audio
'patchbay', or graph. in-process (.so) clients will eventually
be supported by jackd, too, iirc.
if the jack graph is extended to additionally support object/
event-based communication among jack clients, and if a reasonable
degree of freedom is given to client plugins to define these
objects ('port values' in the LADSPA sense for example), 'hosts'
can largely rely on jack functionality for managing plugins.
for example, an audio-processor, IIR-filter plugin may want to
expose a port that receives the cutoff frequency. it accepts a
named object type that is called 'frequency', which is derived
from a 'float' object.
a gui plugin will then 'know' what kind of parameter representation
would be appropriate, by knowing the port type is 'frequency'.
a plugin that wants to express a new type of data is free to derive
from the existing types. if the plugin is useful, this new data
type will automatically (so i hope) be supported by other clients.
meanwhile, the author can always choose to supply a converter or
a dedicated gui.
of course this needn't strictly be integrated with jack. otoh,
combining it with a system-wide timebase opens up another dimension.
tim
This archive was generated by hypermail 2b28 : Wed Sep 04 2002 - 15:43:03 EEST