Hard to jump in the thread at this point, but let me try...
I agree that the plugin approach is severely flawed in many senses
(including the false sense of "freedom" that gives to developers that
are then caught in proprietary specifications). Having a better open
standard like LV2 is a good thing but I see Stefano's point because this
is not going to help promote interoperability, is it?
My humble opinion is that the solution is already sketched out by
existing tools. Imagine an open standard that combines audio streaming
connection a la Jack with control interchange a la OSC. Make it 100%
cross-platform, add a little of Dataflow theory into it to guarantee
proper scheduling and avoiding deadlocks and... voila!
Curiously enough this has a lot to do with another email sent by another
CLAM developer (Pau) to the list ("Data-flow systems integration").
I think an effort in integrating data + control inter-application
communication would be much more worthwhile than following the plugin
route.
Stefano, have you though what your wrapper will suffer when let's say
VST 3.0 is published and you have to rewrite all your stuff simply
because Steinberg has decided to rename a few functions or change the
behavior of many others. Are you going to support a subset of the
specification (like most hosts do)? a subset of all of them? a superset?
Also your talk on LTI makes me think that you are not familiar with
models of computation (e.g. Dataflow Networks). Contact me off-list if
you need good pointers).
Xavier
On Wed, 2007-02-14 at 15:40 -0500, Stephen Sinclair wrote:
> > What about a text file with a math formula within it to be used as a
> > "processing object"?
> > Ok, it's not a piece of code, but...
>
>
> sounds a bit like FAUST.
> http://faust.grame.fr/
>
> steve
--
