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
