Subject: RE: [linux-audio-user] Modular synths of the world, unite and take over :-)
From: Mark Knecht (mknecht_AT_controlnet.com)
Date: Tue Mar 18 2003 - 19:09:49 EET
Hi,
Have any of these soft synths that use boxes and user-based connectivity
(SSM, Octavian, gAlan, Beast, etc.) addressed the issues of polyphony yet?
Mark
> -----Original Message-----
> From: linux-audio-user-admin_AT_music.columbia.edu
> [mailto:linux-audio-user-admin_AT_music.columbia.edu]On Behalf Of Mike
> Rawes
> 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
> 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
>
>
This archive was generated by hypermail 2b28 : Tue Mar 18 2003 - 19:17:06 EET