13 Feb
2007
13 Feb
'07
10:06 a.m.
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. 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.