[linux-audio-dev] processing plugin standard wrapper

[David García Garzón]

On Wednesday 14 February 2007 18:29:15 Stefano D'Angelo wrote:
> 2007/2/14, David García Garzón <dgarcia at iua.upf.edu>:
> > 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. :-)
>
> Well, I hope that Dave knows what he said :-) Currently we are two
> part-time developers (both university students here in Italy) and my
> friend is not very skilled at programming at this level, but he
> whishes to learn.
> Personally, I do what I can.
>
> > > > > 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.
>
> I know that's hard. However the actual wrapper, in my case, is the
> 'Wrapper module'. The 'Wrapper' is just the generic library to use in
> hosts.
> Anyway I'm taking a quite direct approach to the matter: first wrap
> LADSPA, then extend to the processing-side of other systems, then work
> on the UI-side, and at the end experiment with new possibilities...
> few words for a lot of work really :-)
>
> > > > > 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.
>
> I actually don't know how many plugins are LTI, but, for example, a
> lot of delays, reverbs, choruses, eq. filters, compressors, modulators
> and "sound mixers" should be, and that's quite enough after all.
> Consider that in the case of commonly used guitar effects the only
> non-linear effects by their nature should be hardware-simulators
> (valves, amps, etc.), distortions and synths.

Not sure at all, but i thought compressor was an example of non linear 
transformation and they normally have an adaptive behavior which make them 
not time invariant, so you cannot model it as a single H(f). It is very easy 
to find a plugin which has been introduced non-linearity o time-variation 
thought the main function (a filter, chorus, reverb...) is LTI. We are also 
used other kinds of transformations such as sine shifting that are far from 
linear also.

> Anyway (did I say this?) I'm considering also that if a "module"
> contains info on how to generate plugins following the standard they
> wrap, well, I think that CLAM developers could be interested in this
> too. In other words, I'm going my way but I'm seeking for people who
> want to contribute or have some nice ideas or can give useful
> suggestions, and that's why I'm here...

Yes we are, so keep us informed on your progress about plugin system 
integration. We'll do so. ;-)