14 Feb
2007
14 Feb
'07
1:56 p.m.
On Wednesday 14 February 2007 18:29:15 Stefano D'Angelo wrote:
2007/2/14, David García Garzón
<dgarcia(a)iua.upf.edu>du>:
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 :-)
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.
On Tuesday 13 February 2007 15:06:27 Stefano
D'Angelo wrote:
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.
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. > 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. > 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. 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. ;-)