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

Fons Adriaensen fons.adriaensen at skynet.be
Sun Jan 18 00:45:00 UTC 2004


On Sat, Jan 17, 2004 at 08:52:29PM +0000, Steve Harris wrote:

> Hmm... even putting this prediction behaviour in the engine is far too
> specific, what if the voice contains a delay line? for something as
> versatile as a modular synth I think you have to pick one of the
> traditional (and more explicable to users anyway) priority schemes - eg.
> lowest/higest note or last note, which dont rely on any special knowledge
> of the behaviour of each voice.

It's not done by the engine. *All* modules have the option to 'lock' a voice,
protecting it from being re-used for a new note. The logical OR of all these
locks is fed back to the voice controller, which has the option to use
this info or to ignore it. In most cases, the envelope generator that controls
the voice gain will be all that's required. Any linear and stationary 
operation (delay, resonant filtering, reverb) that follows the VCA can be
ignored -- it will just add the new note to the tail of the previous one.
(stationary in this context means: not dependent on events from the VC).

> I'm guessing that you want to kill voices that are finished? Well, my
> guess is that you just can't - not without unexpected things happening.
> It can only done (some) softsynths synths because they know the semantics
> of thier own voices.

No, killing finished voices is not the primary objective. Also, the standard
VC does not really need this info -- it's only used to resolve conflicts
in special cases. The VC I've been testing recently works as follows:

- if there is no 'lock' feedback, the voice that has the 'oldest' note-off
is re-used. If all voices are 'on', the new note is discarded, or optionally,
the voice with the oldest note-on is re-used. 

- if the feedback is used, the VC first checks if there is any 'free' voice,
i.e. one that is not locked. If there is none, the new note is discarded,
or optionally, the previous rule is used. 

(and if there's still a problem after all this, you *definitely* need more
voices :-)

The first rule is really the default, unless you enable the lock feedback
feature. That's why I play with the idea of implementing this feedback as
an explicit control connection instead of metadata, to be used only when
necessary.

This may happen for some 'off-mainstream' types of music, if the oldest note
is not necessarily the one you'd want to replace, or if someone writes some
weird instrument-specific VC (e.g.for a sitar-like instrument). 

Anyway, the modules that want to generate locks can use whatever criterion
they choose - it's really a general purpose mechanism allowing any module
in a patch to protect an existing voice from being killed by the VC. This
enables you to bypass MIDI's rather primitive voice model that is based on
note numbers only. There are some other special features in the VC, available
only if you do not use MIDI, such as explicit voice assignment. Using this,
you can start a new note 'in the context of' a specified existing one, as in
CSOUND's tie-in feature.

> Yes, but "well-known" port labels are very ladspa-y. eg. the latency
> control out port, its not in the spec and it doesnt hurt any apps, but it
> is a useful convention.

What is this latency control port ?
 
> We could define a meta-convention - something like: if the port label
> begines with an _ then it should not generally be shown to users (unless
> the app knows what its for and wants to expose it) as they wont be able to
> do anything useful with it.

A nice idea ! Even better would be '_app_port' where app is the application
that this port is meant for. Or OSC style: 'app/port'.

The problem of MIDI, transport, xxx.., data remains of course, unless we agree
that the application specific prefix implies a licence to override the default
float* type. Another remaining problem is that LADSPA has no callbacks from the
plugin to the host, unless we agree that an app-specific port can be used to
pass function pointers  :-) :-)

But... if I'd use this approach, the resulting modules would be technically
compliant LADSPA plugins, but probably be useless outside JAMS (that's the new
name - the J stands for JACK). One could ask what's the point in that case.
But I'll keep this idea in mind, it *is* nice.

-- 
Fons











More information about the Linux-audio-dev mailing list