[linux-audio-user] Modular synths of the world, unite and take over :-)
mknecht at controlnet.com
Tue Mar 18 12:19:01 EST 2003
Have any of these soft synths that use boxes and user-based connectivity
(SSM, Octavian, gAlan, Beast, etc.) addressed the issues of polyphony yet?
> -----Original Message-----
> From: linux-audio-user-admin at music.columbia.edu
> [mailto:linux-audio-user-admin at music.columbia.edu]On Behalf Of Mike
> Sent: Tuesday, March 18, 2003 8:11 AM
> To: linux-audio-user at music.columbia.edu
> Cc: alsamodular-devel at lists.sourceforge.net
> Subject: Re: [linux-audio-user] Modular synths of the world, unite and
> take over :-)
> --- Lukas Degener <AFBLukas at gmx.de> wrote: > Roman Kaljakin wrote:
> > Sseems we have a little problem.
> > Ok, maybe problem is not exactly the right term, let's put it this way:
> > Right now, there is beast, there is gAlan, there is ams, and of course
> > there is also pd, jmax, etc. and lately Octavian, and, rats,
> there maybe
> > a zillion of other apps out there that i do not yet know of (authors of
> > such apps, please append your project to my list:-) )
> There's SpiralSynthModular (SSM), which I use most frequently
> (I've not tried
> Beast/BSE, nor Octavian).
> > While each of this projects may have unique approaches to certain
> > problems, or use different metaphors for similar things, i
> guess it is a
> > valid assumption, that they all have _very_ similar goals in terms of
> > functionality. At least that was my impression after talking
> with Stefan
> > (beast) and Torben (gAlan).
> > The Big Question(tm):
> > How can we avoid redundant work?
> > My (somewhat utopious) suggestion:
> > maybe we should think in components that use/modify a common
> > datastructure/model.
> Here's my take on this...
> 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.
> The Generalized Music Plugin API discussions
> (http://www.freelists.org/archives/gmpi) are working towards a more
> encompassing API, but it looks to be a long way off.
> 2. A single codebase for building, representing and running graphs (AKA
> networks, patches) of plugins.
> 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
> 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,
> 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...
> > 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
More information about the Linux-audio-user