14 Feb
2007
14 Feb
'07
5:18 p.m.
2007/2/14, Xavier Amatriain <xavier(a)create.ucsb.edu>du>:
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?
Right.
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!
... just a dream? :-)
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?
I mean a superset and I know that's a tremendous amount of work, I do
hope that someone will join in.
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).
I'm going to do it right now. I'm just a beginner in DSP-related stuff
(I have my first DSP exam the day after tomorrow), but it interests me
a lot.
I have some texts on the topic, but knowledge is always welcome :-)
Stefano