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@xxxxxxxxxxxxxxxxxx > [mailto:linux-audio-user-admin@xxxxxxxxxxxxxxxxxx]On Behalf Of Mike > Rawes > Sent: Tuesday, March 18, 2003 8:11 AM > To: linux-audio-user@xxxxxxxxxxxxxxxxxx > Cc: alsamodular-devel@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [linux-audio-user] Modular synths of the world, unite and > take over :-) > > > --- Lukas Degener <AFBLukas@xxxxxx> 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 > >
