6 Jan
2003
6 Jan
'03
11:30 p.m.
Two problems solved! (Well, almost... Still need
temporary space for
the "parameters", unless voice allocation is non-conditional.)
I think if you get an allocate voice event, you MUST get a voice on event.
That doesn't really work for normal polyphonic
instruments, unless
the host *fully* understands the synth's voice allocation rules,
release envelopes and whatnot. The polyphonic synth is effectively
reduced to a tracker style synth with N monophonic channels.
two-way
dialogue, or you have use-once VVIDs. Maybe this is OK -
2^32 VVIDs per synth. The host only really needs to store a small
number - the active list.
Why would the host (or rather, sender) care about the VVIDs that are
*not* active? (Remember; "Kill All Notes" is a Channel Control, and
if you want per-voice note killing, you simply keep your VVIDs until
you're done with them - as always.) VELOCITY can
be continuous - as you pointed out with strings and
such. The creation of a voice must be separate in the API, I
think.
Why? It's up to the *instrument* to decide when the string (or
whatever) actually starts to vibrate, isn't it? (Could be VELOCITY >=
0.5, or whatever!) Then, what use is it for hosts/senders to try to
figure out where notes start and end? Of course - but I don't think it has to be a
two-way dialog for this
reason. And I don't think a two-way dialog can work very well in this
context anyway. Either you have to bypass the event system, or you
have to allow for quite substantial latency in the feedback direction.
I once had the idea that you send all your events in a given block with
negative voice-ids. The plugin responds with the proper per-plugin
voice-id.
Block start:
time X: voice(-1, ALLOC) /* a new voice is coming */
time X: velocity(-1, 100) /* set init controls */
time X: voice(-1, ON) /* start the voice */
time X: (plugin sends host 'voice -1 = 16')
time Y: voice(-2, ALLOC)
time Y: velocity(-2, 66)
time Y: voice(-2, ON)
time Y: (plugin sends host 'voice -2 = 17')
From then out the host uses the plugin-allocated
voice-ids. We get a large
(all negative numbers) namespace for new notes per block.
We get
plugin-specific voice-ids (no hashing/translating). Plugin handles voice
stealing in a plugin specific way (ask for a voice, it's all full, it returns
a voice-id you already have and internally sends voice_off).
I found it ugly at first. I like that it all is plugin-specific. Poke
holes in it?
Note that when a synth starts stealing voices,
that's actually *error
handling* going on. If a soft synth with say, 32 physical and 32
Not necessarily. I've played with soft-synths with no envelope control,
which I wanted to be mono. I set maxpoly to 1, and let it cut off tails
automatically. It isn't _necessarily_ an error.
Tim