Re: [linux-audio-dev] Catching up with XAP

On Wednesday 15 January 2003 10.42, Tim Hockin wrote: Well, thanks. :-) [...] The only problem I have with it is that it's completely irrelevant to continous control synths - but they can just ignore it, or not have the control at all. There's this distinct FX vs instrument separation again. What is the actual motivation for enforcing that these are kept totally separate? I don't see the separation as very intuitive at all. The only differences are that voices are (sort of) dynamically allocated, and that they have an extra dimension of addressing - and that applies *only* to polyphonic synths. For mono synths, a Channel is equivalent to a Voice for all practical matters. It's also totally optional. If you don't care to check the hint, just always use real VVIDs with Voice Controls, and never connect Channel Control outs to Voice Control ins, and everything will work fine. [...] Why? Is there a good reason why a synth must not be allowed to function like the good old SID envelope generator, which can be switched on and off as desired? Also, remember that there is nothing binding two notes at the same pitch together with our protocol, since (unlike MIDI) VVID != pitch. This means that a synth cannot reliably handle a new note starting before the release phase of a previous pitch has ended. It'll just have to allocate a new voice, completely independent of the old voice, and that's generally *not* what you want if you're trying to emulate real instruments. For example, if you're playing the piano with the sustain pedal down, hitting the same key repeatedly doesn't really add new strings for that note, does it...? With MIDI, this is obvious, since VVID == note pitch. It's not that easy with our protocol, and I don't think it's a good idea to turn a vital feature like this into something that synths will have to implement through arbitrary hacks, based on the PITCH control. (Hacks that may not work at all, unless the synth is aware of which scale you're using, BTW.) And when you enter the release phase? If have yet to see a MIDI synth where voices stop responding to pitch bend and other controls after NoteOff, and although we're talking about *voice* controls here, I think the same logic applies entirely. Synths *have* to be able to receive control changes for as long as a voice could possibly be producing sound, or there is a serious usability issue. [...] Sure - but where does it belong, logically? The controller or user might now, but the synth generally doesn't. I'm just suggesting that senders be able to provide useful information when it's there. How? It's obvious for monophonic synths, but then, so many other things are. Polyphonic synths are more complicated, and I'm rather certain that the player and/or controller knows better which not should slide to which when you switch from one chord to another. Anything else will result in "random glisandos in all directions", since the synth just doesn't have enough information. MIDI sequencers are reusing "IDs" all the time, since they just don't have a choice, the way the MIDI protocol is designed. Now, all of a sudden, this should no longer be *possible*, at all...? Either way, considering the polyphonic glisando example, VVIDs provide a dimension of addressing that is not available in MIDI, and that seems generally useful. Why throw it away for no technical (or IMHO, logical) reason? Whatever. A sender should still never leave hanging notes, whatever it's doing, or whatever protocol is used. Anyway, the real point is that you may need to talk to the voice during the release phase; not just until you decide to switch to the release phase. [...] Sure, that's the goal here. I disagree. I think most people expect controls to respond during the full duration of a note; not just during an arbitrary part of it. This is the way MIDI CCs work, and I would think most MIDI synths handle Poly Pressure that way as well, even though most controllers cannot generate PP events after a note is stopped, for mechanical reasons. (It's a bit hard to press a key after releasing it, without causing a new NoteOn. :-) I don't see a good reason to special-case this - and also, there is no reason to do so as long as a VVID remains valid for as long as you *need* it, rather than until the "formal end of the note". c) is what I have a problem with here. Why is the VOICE control becoming so special again, implying destructive things about the VVID passed with it and stuff? This completely eliminates the use of voice controls together with step sequencers. What's the logic reasoning behind that? My other major problem with this is that it makes step sequencers and their synths a special class, in that they're using a different protocol for "voice off". It *might* still make sense to require that all synths implement a special "unarticulated note off", but I'm not sure... Sounds like a different discussion, in some way, and the scary part is that it's still a special case that means senders will have to treat synths differently. Given that I generally program my drum kits to respond to NoteOff anyway, I'm not very motivated to accept step sequencers as something special enough to motivate special cases in the API, but I can see why it would be handy for step sequencers not having to worry about note durations. (The "zero duration note" hack typically used by MIDI sequencers won't work if the synths/patches use "voice off" to stop sounds quicker than normal.) It's just that it can't do things that people expect from every MIDI synth, just because VVID allocation is integrated with the VOICE control. [...] Sure, but how do you suggest we force this upon continous control synths, without breaking them entirely? Explicitly telling a synth how to do something that's basically for the synth author to decide seems a lot more confusing to me than just not assuming anything about it at all. But when are these extra events needed at all? I still don't see what information they bring, and what any synth would use it for. I'm not sure what you mean, exactly. On the protocol level, it's just a matter of having the values in place before the "trigger" condition occurs (normally "note on" or "note off" directly caused by the VOICE control). Controllers and other senders will have to know which controls are init-latched and what triggers the latching of them. There's no way to avoid that, and it should be covered by the API. The VOICE control can be standardized, and then we can have hints for "voice on" latched controls and "voice off" latched controls. Sure - that's why I'm sugesting explicit VVID allocation and detachment events. Quite possible, unless it's legal to use VOICE as a continous control. If it isn't, continous control synth simply won't have a use for VOICE control input, but will rely entirely on the values of other controls. Also, as soon as you want to indicate that a new note is to be played on the same string as a previous not, or directly take over and "slide" the voice of a previous note to a new note, you'll need a way of expressing that. I can't think of a more obvious way of doing that than just using the same VVID. Well, then that conflict is resolved - provided synths are note *required* to take VOICE_ON if they care only about "real" controls. :-) It's hardcoded, or programmed into the patch, depending on synth implementation. I can't see how this could ever be something that the sender can decide at run time. There's no need to "tell" the synth something it already knows, and cannot change. For example, your average synth will have a VELOCITY and a DAMPING (or something) control pair, corresponding to MIDI NoteOn and NoteOff velocity, respectively. You could basically set both right after allocating a voice/VVID, as the only requirement is that the right values are in place when they should be latched. [...] It means the voice doesn't hang at a fixed pitch, with the filter wide open and whatnot, just because you decided to start the release cycle. I've often found myself missing the advantages a monophonic patches have WRT note->note interaction, when using polyphonic patches. I actually think the ability to eliminate this distinction is a major feature that comes with VVIDs. If you can reuse VVIDs, a poly synth effectively becomes N monosynths playing the same patch - if you want it to. If not, just reassign a VVID for each new note. That's just a shortcut, and not really a motivation to be able to reuse VVIDs. Yes, and more importantly, this simplifies the handling of latched voice controls quite a bit. Further, is there *really* any sense in using latched controls with continous control synths? Considering that such controls are usually for velocity mapping and the like, the cases where it would be of any use at all in a continous control synth are probably very few, if there are any at all. That is, continous control synths can just ignore the VOICE control, and everything will just work as expected anyway. (Just connect your VOICE output to the VELOCITY input of the synth, and it'll play, at least.) Yeah, I "heard" - I'm looking at your post right now. (No risk I'm going to comment on it or anything! ;-) //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 ---