Re: [linux-audio-user] Modular synths of the world, unite and take over :-)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] Modular synths of the world, unite and take over :-)
From: Mike Rawes (mike_rawes_AT_yahoo.co.uk)
Date: Tue Mar 18 2003 - 18:11:20 EET


 --- 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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Mar 18 2003 - 18:16:29 EET