19 Mar
2003
19 Mar
'03
2:42 a.m.
On Tue, 18 Mar 2003 16:11:20 +0000 (GMT)
Mike Rawes <mike_rawes(a)yahoo.co.uk> wrote:
1. A unified Plugin API
All of the above softsynths have their own plugin format, for various reasons.
LADSPA (http://www.ladspa.org) has helped with this, making much excellent code
available for all these softsynths. However, the (intentional) simplicity of
LADSPA has prevented the various formats being replaced entirely.
Most of synth (i.e. SpiralSynthModular, AlsaModularSynth, Octavian) have LADSPA
support already. LADSPA is good for filters, but not for oscillators and other
voltage controlled (in modular synths) modules.
2. A single codebase for building, representing and
running graphs (AKA
networks, patches) of plugins.
It might be looks like as a toolkit... maybe.
Almost all of these softsynths are pretty much exactly the same 'under the
hood' - just a connected bunch of plugins executed in a particular order. The
only real obstacle to unifying this is the plugin API issue above.
I'd certainly like to see a unified engine for LADSPA - I've been on-and-off
planning one, but SSM is so close to what I'd like that I'm not motivated
enough :/
My thoughts on engine-things so far (this is all a bit of a brain dump,
apologies:)
No GUI - all functionality exposed through various forms of
Inter-Process Communication (IPC):
Graph State Query and Manipulation (command set for adding
plugins, making connections etc).
Audio I/O - JACK (http://jackit.sf.net) would be the choice here
Control - something like the LADSPA Control
Protocol (http://www.op.net/~pbd/lcp.html)
would be good.
Built-in support for subpatches:
The graph itself could be kept 'flat', with some sort of
abstract representation of subpatches on top of it. Including
ability to 'register' subpatches as plugins.
The thought of being able to set up, for example, a mixer
channel out of multiple LADSPA plugins, register it as a plugin,
and then add sixteen of them to a graph to make a mixer has a
certain appeal :)
----
3. Separation of graph/engine and any UI.
Any UI would communicate with the engine using IPC - this would allow
multiple views of the network - e.g. a wiring diagram for setting up,
a set of knobs'n'sliders (real or virtual) arranged nicely for
performance, commandline scripting, or any combination...
-
Mike
This has almost (but not completly) nothing to do
with merging ;-)
It means that we have to agree on what exactly that common model would
be, and after that, we would go on writing
different components that actualy work with this model. The problem of
course would be to define that model.
But once we have managed this, it should be possible to have different
components cooperate on the same instance of that model at the same
time, without knowing about each other, i.e. all "inter-component"
communication would be established via the model. I tend to think of
this as a "Macro Model/View/Controller" pattern. (i have forgotten the
actual term, something like "Document Oriented Design" i think.)
So this goes out to Matthias, Torben, Stefan, Roman, and of course
everyone else interested in such a thing:
What do you think?
Regards,
Lukas
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com