Hi Tim! Ok, got it, thanks!
This is ok that instruments should treat noteon+zero velocity as note off. But.. Our code for hosting these instruments (I'm thinking of virtual instruments as of hardware ones) - dssihost, lv2host, vst_native - is like a proxy and it should not modify midi messages, just send them to actual instrument (though program changes can be processed individually). And It's up to instrument to work with note on + zero vel as with note off message. By the way - your vst native host works with note-ons as is - without checking velocity and further modifications. Now only dssi host makes these changes. Regards, Andrew 24 дек. 2015 г. 6:30 AM пользователь "Tim E. Real" <[email protected]> написал: > > On December 23, 2015 11:23:20 PM Andrew Deryabin wrote: > > Hi All, > > > > Just pushed new commit, fixing stuck notes. To prove that this patch > > should work right, I'll try to explain my steps. May be these results > > are completely wrong, but here is the explanation: > > > > (IMPORTANT: this results are not related to physical midi inputs - when > > playing on external midi devices, ME_NOTEON and ME_NOTEOFF are sent right). > > > > 1. stuckNotes. I checked the code and decided that this mechanism is > > used for shutting down notes that were not explicitly shut off by note > > offs messages or by some other means. So the only message that should be > > recorded for future post is ME_NOTEOFF (0x80 in midi specs). > > 2. The code from midi.cpp made something strange for adding events to > > stuck notes array. According to midi specs, not only ME_NOTEON, but also > > ME_NOTEOFF can have velocity value. For ME_NOTEOFF velocity describes > > how quickly the note should be released (127 - fast release, 0 - long > > release). For reference: in MusE all noteoffs from virtual instruments > > are sent with velocity value = 0. > > 3. From dssihost.cpp I knew that ME_NOTEON message is used in rather > > interesting way: if supplied velocity value is zero, ME_NOTEOFF message > > is sent instead of ME_NOTEON. lv2host.cpp has the same issue until I > > rewrote midi handling code and removed this check. That's why some > > instruments were stuck on some notes after this change (ME_NOTEOFF was > > not sent at all). > > 4. Again about stuck notes. It seems, that velocity for ME_NOTEOFF > > message is supported by the code. When ME_NOTEOFF is received by midi > > engine, but before it's send to actual midi device, velocity value is > > remembered in event's _veloOff variable. When stuck notes array is > > filled, this value is used as midi event velocity. But (and this is a > > mystery for me) this velocity value was also used for deciding if > > ME_NOTEON (if _veloOff = 0) or ME_NOTEOFF (if _veloOff > 0) was inserted > > to stuck notes. The problem was that stuckNotes was filled with > > ME_NOTEON and velocity = 0. It was ok for this code (from dssihost.cpp): > > > > if(b) > > snd_seq_ev_set_noteon(event, chn, a, b); > > else > > snd_seq_ev_set_noteoff(event, chn, a, 0); > > > > where b is the velocity. > > > > But not ok when this check was not used. As for me, the above code seems > > like a hack. > > > > After forcing ME_NOTEOFF for stuckNotes all things went in a normal way. > > To be sure I added code for dumping midi messages sent to lv2 synths to > > check if it works right. And it did. Every ME_NOTEON message was closed > > with corresponding ME_NOTEOFF. I also added velocity to noteoff message > > in lv2 host code to satisfy midi specs. > > > > P.S. midi_engine_fixes branch also have this problem, but because of > > older version of lv2host.cpp (which handles ME_NOTEON with velocity=0 as > > ME_NOTEOFF) everything worked right. > > > > Regards, > > Andrew > > Howdy. > > Here is the reasoning for this long-time code, Robert and others > might chime in here: > > First, in MIDI a note on with zero velocity is essentially same as note off. > > Next, to conserve both MIDI interface bandwidth and MIDI file space, > there is something called 'running status': > If the status byte of the next desired message to be sent happens to be > the same as the /last/ status byte that was sent, then this next status > byte can be /omitted/. > Note on and note off are two /different/ status bytes, thus it would be > required to include both with /every/ note on - note off message pair. > > So, for a note off, they just use a note on with zero velocity, so that the > status byte does not change and can be omitted from the steam or file, > even for a whole run of many notes (that's where the savings come in). > Many MIDI manufacturers and software developers do this. > Refer to MusE Settings -> Midi import/Export and see the export option > "Save space by replacing note offs with zero velocity note ons" > > Concerning the MusE synthesizers: > Perhaps you can now see why that DSSI code was not really a hack > but a final 'decoding' of these 'zero velocity note ons' into 'real' > MIDI note off messages before they are sent to the DSSI synths. > > That is what happens inside your midi keyboard when it receives zero > velocity note on messages from MusE. > > And, that is what you should try to do /inside/ MusE's LV2 code. > > (Although not intimately familiar with the LV2 code, it struck me that > only your LV2 code was having problems and the other synths were OK.) > > Could we /leave/ them as 0V note ons when they're sent to the synths? > I dunno... likely some are OK with it some not. But I think the reasoning > for decoding before being sent might be: > "Why not (decode it now)? We've plenty of bandwidth at this level, > and why risk sending 0V note ons to a synth that doesn't like it...", > > Could we add an extra Setting (like the export option mentioned above), > which applies to the realtime messages being sent /out/ from MusE, > for users who are not happy with the 0V note ons? > Sure, I suppose it might help in some cases. > Better than no option for that, eh? > > > Sincerely hope I got that all correct ;-) > Tim. > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Lmuse-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lmuse-developer ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
