[linux-audio-dev] processing plugin standard wrapper

[David García Garzón]

On Tuesday 13 February 2007 15:06:27 Stefano D'Angelo wrote:
> > Yes, it's very interesting and it is a path we want to walk. Currently,
> > apart of building Ladspa plugins, CLAM also can be a Ladspa host and we
> > should extend that to other plugins systems. We have two students in our
> > lab working on plugin and hosting aspects, but they need some time for
> > any outcome.
>
> Well, CLAM is a big and important project and I am just an unknown
> student from Italy who is trying to develop a replacement for pedal
> boards and stomp boxes and trying to let people easily reuse the code
> I'm going to write.
> Anyway, if you think that me and/or my project
> (http://freeadsp.sourceforge.net - the site is not being updated since
> we're working on a new one) can contribute, I/we'll be pleased to.

Nice. It is one of the promissing new projects Dave Phillips reported in its 
blog, so it will deserve a close look. :-)

> > > But, anyway, maybe combining the two things could be of some interest:
> > > imagine that you want to be able to develop and use immediately in all
> > > supporting applications a plugin system capable of using the
> > > z-transform.
> > > In this way you could build a module for this wrapper and
> > > soon start programming your plugins and use them, without having to
> > > wait for the adoption of "your standard".
> >
> > CLAM is not an standard to be adopted. Alsa, Jack and so on are the
> > standards. CLAM should be a convenience implementation tool. Migration is
> > something that can not be expected and we have a lot of experience on
> > that. I am for providing interframework wrappers so everyone could
> > develop on the framework he is used to (Mathlab, Marsyas, Pd...) and
> > still reuse what it is done in other frameworks.
>
> I think it's clear that I'm not talking about a new standard and
> things like that. I'm talking mainly about a wrapper. The possiblity
> to develop new formats and have them working with any app that uses
> such wrapper comes directly from the nature of the wrapper itself...
> In other words I was just wondering how things could go after such
> thing would be ready and working.
> Then, to be honest, I think that if I/we succeed with implementing a
> clean way to make VST, LADSPA, LV2, DSSI, etc. work well together,
> some already started projects would at least consider the chance of
> using such framework.

> To be even clearer the "integration" I was talking about could work like
> this:
>
> Host -> Wrapper -> Wrapper module (plugin loader - one per standard)
> -> Processing object (plugin)
> In this case the host needs information on how to use a processing object.
> But if you put inside such wrapper module also information on how to
> build a processing object from an algorithm, than CLAM could use the
> same interface to do that other thing.

That would be great. Our main motivation for looking for hosting plugins (or 
other implementation platform such pd) in CLAM that is to give reuse options 
to people developing with CLAM. Providing an adapter layer among plugin 
systems is a side effect that may occur some time later. But note that so 
many layers is not the best option for performance so wrapping the wrapper 
should not be the first option.

Splitting with an interface between what you call 'Wrapper' and 'Wrapper 
module'  ('Audio System Backend', and 'Plugin adapter' in our vocabulary) is 
a good idea as it eases the effort from NxN adapters to 2xN. But still is a 
hard task to define such intermediate interface that we are designing 
incrementally. My advice to you is not to generalize so much at  the 
beginning.


> > > Also, this way some noticeable improvements can be made on performance
> > > if this wrapper would be able to represent processing networks which
> > > can be "simplified", as for example a net of LTI systems with known
> > > transfer function (fourier transform).
> >
> > Sorry, I don't understand you here.
>
> It's quite simple: if you have a processing standard which represent
> processing objects as LTI (linear time-invariant) systems using the
> fourier transform of their transfer function (books often call this
> H(f)) and you arrange such objects in a network, then, instead of
> calculating outputs for each object, you can just multiply all H(f)s
> following a certain path and use this result as the H(f) of the whole
> network. This would allow network-based optimization (but obviously
> the wrapper would have to know how the net is made).
> Well, it seems like you're a teacher or a researcher, so you probably
> know more than me about these stuff.
> This, however, is just a thought.
> In case I wasn't clear enough, just tell me.

Ok, i get the context now. As you say, I'am both teacher and researcher, but 
my field is Software Engineering and my knowledge on theoretical DSP is not 
that mature, so don't take my DSP related statements so serious. To my level 
of knowledge, i could say that most of the plugins are not just LTI so, the 
kind of optimization you suggest would be not general just appliable to 
consecutive adjacent LTI systems. At the same time is something that may have 
a lot of sense in FreeADSP.

David.