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

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

Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Dave Robillard (drobilla_AT_connect.carleton.ca)
Date: Mon Jan 19 2004 - 04:03:45 EET


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


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

This archive was generated by hypermail 2b28 : Mon Jan 19 2004 - 04:10:07 EET