Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Fons Adriaensen (fons.adriaensen_AT_skynet.be)
Date: Sat Jan 17 2004 - 14:32:17 EET
On Sat, Jan 17, 2004 at 10:20:00AM +0000, Steve Harris wrote:
> Thats true, but the voice controller is generally part of the host
> environment, not a plugin. It would typically be the think wihich is
> resonsible for splitting the MIDI data to multiple sub-patches and routing
> the CV streams (velocity, aftertouch) appropraitly. The modules within the
> sub-patch can be completly ignorant of the voice allocation.
Putting the voice controller in the host doesn't solve the problem, as it
still needs info from e.g. the envelope generators. So how will that info
be passed when using LADSPA as the module format ? We could add a hint
saying that a particular output port carries this type of data, but I
wouldn't dare propose such a thing -- in contrast to the 'send NULL pointer
hint' we discussed earlier, this one is far too specific. Or the host could
check for a particular port name -- same problem. Adding some sort of port
type could solve the problem, but that's a major change. It's again that
little bit of generality that's missing.
\begin{aside}
But even this could be added in a backwards-compatible way, for example:
- if hint bit 31 is set, this means that the whole port description is
application specific, with hint bits 16..30 identifying the application,
and bits 0..15 and the other port description items defined by the
application. Application IDs are allocated in the same way as plugin
numbers. It's up to any host to accept a particular ID, or to refuse to
load a plugin it can't handle. All this is probably very un-LADSPA-y :-)
\end{aside}
Anyway, in the new AMS the VC will be a module and preferably a plugin.
Some types of music or application could require a non-standard VC, and I
want the user who needs such a thing to be able to write it and plug it in.
This of course means that the plugin should have access to MIDI data,
and to the file system (e.g. a VC that reads a CSOUND score), and
that creates another interface problem.
Others wil of course arise as the design evoluates, for example things
related to (JACK) transport awareness. So iff I would use LADPSA as the
module format, I could go one of two courses:
- Hijack LADSPA, add all the things I need trying not to break anything,
and present the result as an accomplished fact. I would need lots of
fire protection when that happens, and deserve it.
- Present each and every extension to the LADSPA community, go through
the normal discussion process and hope for the best. This will take lots
of time, could lead to nasty inconsistencies when part of a proposal is
accepted and another part is rejected or amended, and in the end would
mean that my entire desing has to be vetted by this list, since most
functionality will be in the modules. I don't think I would accept that.
Please don't take this as criticism on the fantastic work that you and
others have contributed, but ATM I can't escape the conclusion that the
LADSPA format is too limited to be used as the module format for the synth
I want to write. But I will of course support LADSPA -- there are far
too many nice plugins available, and ignoring this would be just stupid.
-- Fons
This archive was generated by hypermail 2b28 : Sat Jan 17 2004 - 14:38:19 EET