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