8 Jan
2003
8 Jan
'03
5:43 p.m.
On Wednesday 08 January 2003 10.01, Tim Hockin wrote:
[...]
All this is ok in concept. I still think it is too
implicit and it
feels 'sneaky'. I'd MUCH rather see a rigid, well-defined protocol
that forces the few bizarre instruments to do a bit more work
(really, just a BIT) than a loose, implicit one that is going to be
easy to screw up.
What's implicit about it, and how can you screw it up?
If a MIDI synth gets Poly Pressur or NoteOn/Off events, it has to
handle them properly. The MIDI pitch is the "VVID".
This is exactly the same thing, only a VVID does not imply a note
pitch value.
As to VVID management, that's a separate issue, and I'm just looking
for the cleanest and simplest approach. I still think VVIDs with a
host global table of VVID entries is the simplest way that can
actually work, but there are other ways - maybe even simler ways.
VOICE_ALLOCATE: declare a VID as in-use
Ok, this eliminates the need for ever checking VVID entries in a
synth. Good.
(Although the name is probably not right. You don't really care
whether you get a physical voice or not, and it doesn't matter to the
sender. It can confuse things, though - see below.)
VOICE_CONTROL_SET: set values for a per-voice control
for a VID
Yes - and this is where your average synth will have to allocate a
voice (or a fake "control tracer" voice) - unless it's done in
VOICE_ALLOCATE.
Anyway, it's optional for synths. My only argument against
VOICE_ALLOCATE is that it is redundant. Sending any other event to a
Voice could have the same effect, and would also bring more
information. (The only information VOICE_ALLOCATE brings is "the
sender is about to use this voice ID at some point".)
VOICE_ON: declare that a VID is ready for play
I still don't really see the point with this one. Synths will have to
allocate a voice as soon as the first voice control event arrives
anyway, so all this says is "start a note!" - and that doesn't even
apply to continous velocity instruments.
Sure, I can see where VOICE_ON can be a handy feature (the gong, for
example), but it's not strictly related to voice allocation or
anything like that; it's just a form of control data. I don't see
what justifies making this more special than a "standardized" NOTE
control.
Any VOICE_CONTROL_SET for a VID that does not exist is
discarded.
Or just never talk about VVIDs you haven't "initialized". Seems dead
simple to me, since all you have to do is VOICE_ALLOCATE(vvid) at
least once before you start using 'vvid'.
(This is where I find "VOICE_ALLOCATE" confusing. To the synth, is an
"allocated VVID" one that currently has a physical voice, or does any
initialized VVID count? I can see sequencer and synth coders using
the same term for two rather different things, if the term "ALLOCATE"
is used for this.)
I don't think there is any instrument for which
this can't work.
Right - it's just slightly too much redundancy for my taste. ;-)
Seriously, though; there has to be *one* of DETACH_VVID and
VOICE_ALLOCATE. From the implementation POV, it seems to me that they
are essentially equivalent, as both are effectively used when you
want to say "I'll use this VVID for a new context from now on."
VOICE_ALLOCATE is obviously closer to the right name for that action.
It may not be a perfect fit for some, but I think they
are the vast
minority.
This model fits and doesn't taste too bad.
Well, some synths may ignore VOICE_ON entirely, so I don't see why it
deserves to be special, but that's my only real problem with this.
Can't see a technical problem with VOICE_ON, though.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---