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 ---
