2007/1/22, Dmitry Baikov <dsbaikov(a)gmail.com>om>: I'm thinking about a (fat) union API. Well, it depends on how big is the difference... this is a reason why I'm asking you if you think this is possible... after all I know just about VST, LADSPA 1.1 and LV2, and they don't seem to be that much different (I mean at a logical level). Good point! This is true, but there are lots of sound processing plugins around, so maybe instead of creating a new API and then apply some "compatibility layer", it should be better to create a wrapping tool natively. I think it should be also easier to expand. True, but I was thinking about a more "sophisticated" idea of "processing object". For example you might want to write a library to implement sound processing with already-instructed neural networks, and you wish to load values from a text file (which would actually be your "processing object"). With this ideal architecture you don't have to create a new engine from scratch and wait for other programmers to implement it. You would just write a module, and that would work with any program using this system. I know my English isn't perfect, I do what I can. :-) Stefano P.S.: I think I've also found a name for it: "Naspro", an recursive acronym meaning "Naspro Architecture for Sound PRocessing Objects". The "Naspro" is a southern italian type of icing used for sweets.

2007/1/22, Dmitry Baikov <dsbaikov(a)gmail.com>om>: That could be a very wise solution, but there's one big problem with it: when you load a LV2 plugin, you load only one plugin! To be clearer I make an example: I have 10 VST plugin, and I want to write a LV2 plugin which loads VST plugins. When the LV2-aware application asks me which plugin I want to load I should specify the VST plugin loader... but then? There's no way for my LV2 plugin to determine which VST plugin it should load. But also if this is an overcomeable problem, for each VST plugin I load I have to waste memory space with a new instance of the LV2 VST loader plugin. Then, it is quite absurde from the user point of view to open a plugin which lets you open other plugins... it's just illogical! Don't misunderstand me, LV2 is great, I think that it's the best processing architecture out there, but it's designed with a 1:1 relationship in mind (one plugin = one effect). That's absolutely not an LV2 weakness, it just does its job and nothing else (as it should be). Here I'm talking about a different problem: interoperability beetween different processing paradigms, letting the user choose what he likes more. Regards, Stefano

2007/1/22, Leonard Ritter <contact(a)leonard-ritter.com>om>: Well, what do you mean for "extensible DSP plugin system"? Let me know, Stefano

On 24 Jan 2007, at 15:06, Jay Vaughan wrote: Hum. I'm reminded of the often used thought process: "hmmm, there are way to many standards in this area, what we can do to improve things is add another, that would be great!". The way to help, IMHO, would be to make the existing systems compatible, using bridges/reflectors/wrappers, rather than creating more specs. - Steve

On 24 Jan 2007, at 18:04, Stefano D'Angelo wrote: Not necessarily. In my opinion, often a 90% solution that reuses existing technology is better than a 100% one that involves reinventing the wheel. Even if the new wheel is a bit more round :) It's all somewhat a matter of taste though. - Steve