Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Sat Jan 17 2004 - 22:52:29 EET
On Sat, Jan 17, 2004 at 01:32:17 +0100, Fons Adriaensen wrote:
> 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.
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.
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.
I think the best you can do is some kind of (configurable?) timeout after
the note off event is sent whihc causes the voice to fade out and be
killed.
> \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 :-)
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.
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.
- Steve
This archive was generated by hypermail 2b28 : Sat Jan 17 2004 - 22:56:21 EET