#1365 Problems recording "zero duration" MIDI notes

Future Release
Ted Felix

In 12.12 Build 13120

I'm having intermittent problems with MIDI data generated by an Alesis DM5 drum module, which produces Note on/off pairs in "almost instant" succession, far faster than a keyboard being prodded. This is triggering odd behaviour.

Alesis sends (for one drum hit)

00000070 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 9a 26 67 26 00 |øøøøøøøøøøø.&g&.|
00000080 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 fe f8 f8 f8 |øøøøøøøøøøøøþøøø|

"Noteonnoteoff", all in a rush.

This is always passed THRU ok and always appears to be recorded. It always appears on matrix, it always has velocity, it doesn't always play back. Looked at the event list for clues :-

The duration of this "note" in the event list varies from 000-00-00-00 to 000-00-00-04 depending on how hard the MIDI arrives. The notes with duration "000-00-00-00" are always the ones not emitted. No MIDI data arrives at the synth (activity light on synth doesn't blink). It's as if RG has decided not to send it.

Attempting to grid-quantize (1/16) one of these zero length notes causes it to vanish, from the matrix view AND the event list. That's not good.

I tried to create a minimal example .RG file of this, but failed, as saving and reloading the file causes all the zero length events to get a length of 00-00-00-01 (1 notch up from nothing). And now they play back ok! Saving the file seems to be filtering and modifying/correcting the data? Or is it on loading?

So a work around is to save everything straight after recording, then Ctrl-R to reload. But this is clearly not right :)

Attached pictures of what it looked like, 1) the "zero length" events, 2) what they look like on matrix, 3) result of quantize.

2 Attachments


1 2 > >> (Page 1 of 2)
  • Ted Felix
    Ted Felix

    Can you try recording the drum module with arecordmidi? That might create a .mid file that has the noteon/noteoff close together. Then try sending that into rosegarden's record input using aplaymidi and record it. If this gives you the same problem, then attach the .mid file from arecordmidi and we can use it for testing. Let me know if you want more detailed steps.

    • Mike

      I totally followed those instructions, and you're right ...

      aplaymidi/arecord midi will capture the DM5 output and replay it correctly.

      The same file through "aplaymidi --port 128:0 alesis-out.mid" into a waiting instance of RoseGarden: Sounds ok as it records, plays back with missing events. Attached -- the midi file that I sent into aplaymidi.

    • milestone: None --> Future Release
  • I worked on zero length durations during import a long time ago. Zero durations do cause the sort of problems you describe, and the idea was to address the issue by preventing them from happening.

    That works for import, but aparently not for recording. I'm with Ted on having a sample file to test with. That would be handy.

    When I looked into this before, I left the following comment in src/base/Event.cpp

    // Check for zero note durations and fix it (fixing in setters and
    // constructors is problematic since -1 durations are used in recording
    // and many events are indeed 0 duration events.

    I no longer remember why -1 durations are used in recording, and don't see an answer to that close at hand.

    This could be a good puzzle for someone like Ted to untangle, but I'm afraid I simply don't have time to look into this again.

    In the meantime, saving and immediately reloading is a very legitimate workaround in this case, because reloading will specifically invoke the code meant to avoid this issue. Zero durations won't survive reloading, and that should get things to a workable state.

    • Mike

      As requested, attached test files.

      I fear it won't do much good though, as the problem is definitely being fixed during SAVING.

      I created a "bad" recording, with unplayed zero-duration events. Saved it. Then reloaded and resaved as a new name. Diffing the two -- no difference. So it's not reloading that's correcting it, it's saving. Still, here they are.

      • You're absolutely right. It's Event::toXmlString() or something quite like that where I put my fix. This gets invoked at different times having to do with moving to and from XML, so while I'm correct that it gets invoked at import of a .mid file, you're also correct that it gets invoked when saving in native XML too.

        Thanks for the raw .mid test file. Importing it will do nothing, but playing it with something else and recording it into Rosegarden should invoke the code we're interested in.

        (In the meantime, remember the workaround. At least it specifically addresses exactly this kind of thing, even if it isn't convenient.)

        • Or does it get invoked on import? Why would we be converting raw MIDI to XML? We wouldn't. I'm guessing there's another fix in there on that side of things too, or maybe it just works when saving after all, and my memory is completely wrong.

          No matter. There's definitely code somewhere that can be reached, so that's what counts.

        • Mike

          The workaround isn't too bad, Ctrl-S, Ctrl-R, very handy that Ctrl-R loads the most recently used file!

          Otherwise, I'll leave this one with you to figure out the real fix.

  • Ted Felix
    Ted Felix

    I no longer remember why -1 durations are used in recording

    IIRC, a duration of -1 means we have the note-on, but don't have the note-off yet. It's something like that anyway. I recently documented it in the relevant areas, so a bit of digging will find the correct answer pretty quickly.

  • Ted Felix
    Ted Felix

    • summary: Problems with "zero duration" MIDI notes --> Problems recording "zero duration" MIDI notes
    • assigned_to: Ted Felix
1 2 > >> (Page 1 of 2)