[linux-audio-dev] Project: modular synth editor

[Dave Robillard]

On Sun, 2004-01-18 at 20:40, Fons Adriaensen wrote:
> On Sun, Jan 18, 2004 at 06:50:19PM -0500, Dave Robillard wrote:
> 
> > Well, regardless of what the voice does after note release, the voice
> > you want to 'take over' is /probably/ the one with the oldest note-off.
> > I actually implemented an (un-released) quasi-polyphonic MIDI plugin for
> > SSM that worked like this, and it was fine (and I played alot of keys on
> > it).  I can't really think of a case where this isn't sufficient.
> 
> For most (99%) types of music/instrument, that will work perfectly. But I
> can easily imagine situations were this will break down.

You can probably imagine situations where trying to determine is a voice
is "done" (AMS-style) with metadata streams will break down too. ;)

> > I'm saying all sound generating/modifying modules could be.
> 
> Yes and no. The sound processing part can be, but a module needs some
> other components. There's also the data required to manage connections,
> polyphony, and maybe other things. The object-oriented, C++ way to write
> such a system is to create a base class that takes care of all this, and
> define a module as anything you like as long as it derives from that
> base class. That means that everything a module cq. plugin needs is
> *inside* the module cq. plugin, [snip]

Well, from the code perspective, the modules themselves will have to be
wrapped with something, yes.  I was talking about from the user
perspective.  Basically, you "load a LADSPA module" and not some other
crazy format.

So all the audio stuff would be just a plain old LADSPA plugin (which is
a good thing - we've certainly shown LADSPA is capable of this) and
anything else is just a part of your wrapper code (which should be the
same for every plugin thus doesn't need to be stored on disk) 

> 
> Now if you say module == LADSPA plugin, that would mean that
> - either you abandon that architecture, put the sound processing part
> into the LADSPA part and let the host add the base_class functionality
> for each module that is loaded

Doesn't sound like a bad idea to me, unless I misunderstand you. 
Essentially you have a "module" class that contains a LADSPA plugin. 
The host itself will indeed take care of connections and whatnot.

I say putting "who I'm connected to" and information like that in the
plugin is a bad design decision, LADSPA or not.  Store that in the
patch.

-Dave