Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Fons Adriaensen (fons.adriaensen_AT_skynet.be)
Date: Mon Jan 19 2004 - 03:40:53 EET
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.
> Maybe if you had a synth that split notes, and lower notes had really
> really long envelopes, but higher notes were 'plinkey', but come on.
Lower notes having a longer release is quite natural actually. But I was
really thinking about off-mainstream types of music in this context.
> I think pretty much everyone agrees that one or two things in a synth
> can't be LADSPA plugins.. basically all the input/output stuff you
> mentioned.
Well, they *can* be. There's nothing that prevents a LADSPA plugin from
creating a new thread for things that can't be done in the process call.
So a LADSPA plugin that e.g. plays back samples is certainly possible.
But then either the host isn't aware of what this plugin is doing, or you
have to abuse ports to pass things such as alsa sequencer handles, port
numbers or file names.
> 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, and the only per-module data that is
kept by the host is one base class pointer per module. The current AMS
is built like this. For example the processing graph traversal is not
an algorithm implemented in the engine (as it is e.g. in JACK), it is
just the result of the engine calling all 'terminal' modules (those that
have no outputs). All the rest is done by a recursion implemented in the
base class. I like this architecture, and will need some strong arguments
in order to change it.
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,
- or you abuse the LADSPA ports to implement interfaces they were never
meant for, with the result that you have a 'compliant' plugin that will
be useless outside the host it was designed for.
-- Fons
This archive was generated by hypermail 2b28 : Mon Jan 19 2004 - 03:47:11 EET