On Wednesday 14 February 2007 18:29:15 Stefano D'Angelo wrote: > 2007/2/14, David García Garzón <[EMAIL PROTECTED]>: > > 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. ;-)
