midi note off messages lost

You're new to the LinuxSampler world? You don't know where to start and nothing works? Here's the place to ask for help.
Post Reply
camobrite
Newbie
Posts: 20
Joined: Sat Mar 14, 2009 12:28 am

midi note off messages lost

Post by camobrite » Tue Jun 08, 2010 5:46 pm

Hi, I'm having a problem with midi note off messages that i'm wondering if this board can help me with. I'm using qtractor as a sequencer, and whenever I have two of the same note playing immediately after each other, the note off message in between seems to get lost and the first note keeps playing. This only happens when there is no space in between the notes, such as a quarter note C played immediately after a quarter note C. I'm triggering drum loops (so I want no space in between the notes) and the loops just keep playing on top of each other instead of one right after the other. Is there some kind of minimum space between midi messages that linuxsampler can handle, or could this be a problem with qtractor?

-B

ccherrett
Advanced User
Posts: 162
Joined: Wed Jan 23, 2008 11:24 pm
Contact:

Re: midi note off messages lost

Post by ccherrett » Tue Jun 08, 2010 6:27 pm

Sounds like a qtractor bug to me.
Christopher Cherrett
Founder of The Open Octave Project
http://www.openoctave.org

camobrite
Newbie
Posts: 20
Joined: Sat Mar 14, 2009 12:28 am

Re: midi note off messages lost

Post by camobrite » Sun Jun 13, 2010 11:38 pm

I've confirmed that this is happening with seq24 as a sequencer as well. It happens the most frequently with quickly repeated notes, almost like a buffer is overflowing and the noteoff messages are getting lost. Does anyone know if there's some sort of ALSA midi buffer that can be made bigger?

User avatar
cuse
Developer
Posts: 366
Joined: Wed Jan 23, 2008 10:07 pm
Location: Germany

Re: midi note off messages lost

Post by cuse » Tue Jun 15, 2010 5:23 pm

I remember such a bug where note on / note offs were lost with the exact time stamp, but we fixed that a while ago, no idea when exactly. Are you using the latest version of LinuxSampler from CVS?

camobrite
Newbie
Posts: 20
Joined: Sat Mar 14, 2009 12:28 am

Re: midi note off messages lost

Post by camobrite » Tue Jun 15, 2010 8:21 pm

I've done some more testing and it turns out that there may be a qtractor bug or I may have a system configuration issue since I'm experiencing the same behaviour with xsynth under qtractor - note ons and note offs are sometimes and unpredictably getting lost if they have the same timestamp. However, this is not the case with seq24 - xsynth is triggering just fine, while linuxsampler loses noteoffs. I guess this isn't really a conclusive test, since there's only two sequencers and two sound modules. Any suggestions on how to test/configure my system to diagnose this? Or can anyone recommend a rock-solid midi sequencer with a piano roll for linux? I'll bring this up with linux audio users and report back. I can't really make music while I have this problem.

I'm running linuxsampler 1.0.0cvs3 on an eeepc 1005HAB with ubuntu 9.10 (I know it's kind of underpowered which may also be why I'm having issues, but I'm just trying to do really basic stuff)

By the way this board rocks :)

User avatar
cuse
Developer
Posts: 366
Joined: Wed Jan 23, 2008 10:07 pm
Location: Germany

Re: midi note off messages lost

Post by cuse » Tue Jun 22, 2010 11:32 am

I can't say which sequencer is rock solid in this matter. Best thing would be to debug this on the sampler side to see which note on / off events are actually arriving at which time. You can place a debug message in src/engines/AbstractEngineChannel.cpp.

Are you using JACK or ALSA for MIDI input? The ALSA driver in the sampler is using the two methods:

void AbstractEngineChannel::SendNoteOn(uint8_t Key, uint8_t Velocity) [line 281]
void AbstractEngineChannel::SendNoteOff(uint8_t Key, uint8_t Velocity) [line 348]

while JACK is using instead:

void AbstractEngineChannel::SendNoteOn(uint8_t Key, uint8_t Velocity, int32_t FragmentPos) [line 314]
void AbstractEngineChannel::SendNoteOff(uint8_t Key, uint8_t Velocity, int32_t FragmentPos) [line 381]

The difference is that JACK already supplies an exact time stamp (FragmentPos) whereas for ALSA the sampler has to generate the time stamps in realtime by itself and stick it to the sampler's event for further processing.

camobrite
Newbie
Posts: 20
Joined: Sat Mar 14, 2009 12:28 am

Re: midi note off messages lost

Post by camobrite » Thu Jun 24, 2010 5:18 pm

Thanks for this, I'll try this out this weekend

camobrite
Newbie
Posts: 20
Joined: Sat Mar 14, 2009 12:28 am

Re: midi note off messages lost

Post by camobrite » Sun Jun 27, 2010 1:58 am

OK so I added debug output to the midi note on and note off functions (thanks open source :) ) and it looks like notes are actually being received by linuxsampler in the wrong order when they come from qtractor, so there must be a bug in qtractor or a problem with alsa midi. However, when I use seq24, the midi messages arrive in the right order but the audio output is wrong with notes still overlapping, so there must also be a bug somewhere in linuxsampler. This is consistent with xsynth having problems with qtractor but not seq24. Just to be clear, I'll tell you what I did. First, I added a debug message to AbstractEngineChannel::SendNoteOn(uint8_t Key, uint8_t Velocity) and AbstractEngineChannel::SendNoteOff(uint8_t Key, uint8_t Velocity) so they look like this:

Code: Select all

    void AbstractEngineChannel::SendNoteOn(uint8_t Key, uint8_t Velocity) {
        if (pEngine) {
	  printf("note on: %d\n", Key);
            Event event               = pEngine->pEventGenerator->CreateEvent();
            event.Type                = Event::type_note_on;
            event.Param.Note.Key      = Key;
            event.Param.Note.Velocity = Velocity;
            event.pEngineChannel      = this;
            if (this->pEventQueue->write_space() > 0) this->pEventQueue->push(&event);
            else dmsg(1,("EngineChannel: Input event queue full!"));
            // inform connected virtual MIDI devices if any ...
            // (e.g. virtual MIDI keyboard in instrument editor(s))
            ArrayList<VirtualMidiDevice*>& devices =
                const_cast<ArrayList<VirtualMidiDevice*>&>(
                    virtualMidiDevicesReader_MidiThread.Lock()
                );
            for (int i = 0; i < devices.size(); i++) {
                devices[i]->SendNoteOnToDevice(Key, Velocity);
            }
            virtualMidiDevicesReader_MidiThread.Unlock();
        }
    }

Code: Select all

    void AbstractEngineChannel::SendNoteOff(uint8_t Key, uint8_t Velocity) {
        if (pEngine) {
	  printf("note off: %d\n", Key);
            Event event               = pEngine->pEventGenerator->CreateEvent();
            event.Type                = Event::type_note_off;
            event.Param.Note.Key      = Key;
            event.Param.Note.Velocity = Velocity;
            event.pEngineChannel      = this;
            if (this->pEventQueue->write_space() > 0) this->pEventQueue->push(&event);
            else dmsg(1,("EngineChannel: Input event queue full!"));
            // inform connected virtual MIDI devices if any ...
            // (e.g. virtual MIDI keyboard in instrument editor(s))
            ArrayList<VirtualMidiDevice*>& devices =
                const_cast<ArrayList<VirtualMidiDevice*>&>(
                    virtualMidiDevicesReader_MidiThread.Lock()
                );
            for (int i = 0; i < devices.size(); i++) {
                devices[i]->SendNoteOffToDevice(Key, Velocity);
            }
            virtualMidiDevicesReader_MidiThread.Unlock();
        }
    }
Then I compiled and reinstalled with apt-get and dpkg. I fired up jack, qtractor, and linuxsampler. I set up a simple looping sequence in qtractor that just played D4 quarter notes (midi note 60) right after each other at 90 bpm. This was the output of linuxsampler:

Code: Select all

note on: 62
note off: 62
note on: 62
note on: 62
note off: 62
note on: 62
note off: 62
note off: 62
note on: 62
note on: 62
note off: 62
note on: 62
note off: 62
note off: 62
note on: 62
note on: 62
note off: 62
note off: 62
note on: 62
note off: 62
note on: 62
note off: 62
note on: 62
note on: 62
note off: 62
note on: 62
note on: 62
note off: 62
note off: 62
note on: 62
note off: 62
As you can see there's an equal amount of note ons and note offs being received, but they're getting received out of order. The result was that some notes didn't play and some notes overlapped.

When I tried the same setup with seq24, I got the correct ordering of notes received but still had audio output problems. At 90 bpm, the audio output was fine with notes playing one right after the other and not overlapping. The debug output was this:

Code: Select all

note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
As you can see the note ons and note offs are in the right order. However, when I sped up the sequence to 180 bpm, the notes were being received at linuxsampler in the correct order, but there were problems with the playback - notes were overlapping occasionally as if some note off messages were not being processed. Here's the output from the 180 bpm run, so you can see that they were being received at linuxsampler in the right order but producing the wrong audio output:

Code: Select all

note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
note on: 60
note off: 60
However the tale gets stranger still. When I altered the sequence to make it alternating notes, instead of a repeating note, I got the correct audio output at any bpm, so it looks like this is a bug that only affects repeated notes. Here's the debug output for the sequence that produced the correct audio output:

Code: Select all

note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
note on: 64
note off: 64
note on: 60
note off: 60
So my interpretation of this is that there's a bug in qtractor causing it to output midi messages with the same timestamp in a non-deterministic order, and there's a bug in linuxsampler that causes noteoffs to be non-deterministically dropped during repeated notes with the same timestamp. Either that or there's something wrong with my system. I haven't made any realtime customizations to my kernel, as recommended here, but I'm not having latency issues, just this problem with repeated notes in linuxsampler. Should I file a bug report?

linuxsampler version 1.0.0.cvs3

-B

User avatar
cuse
Developer
Posts: 366
Joined: Wed Jan 23, 2008 10:07 pm
Location: Germany

Re: midi note off messages lost

Post by cuse » Mon Jun 28, 2010 12:28 pm

Yes, looks like there could be a bug on sampler side regarding processing note on / off sequences. And sure you can open a bug report. It would be helpful if you could debug this a bit deeper.

Alex
Moderator
Posts: 316
Joined: Wed Jan 23, 2008 9:08 pm

Re: midi note off messages lost

Post by Alex » Thu Aug 26, 2010 11:10 am

Just a quick heads up here. It's fairly common practise using many sample libs to leave a tiny gap between notes, to avoid precisely this kind of scenario. A note off may be sent, but some samples use the note off to trigger a release, and the note may have in fact not ended, as one would assume sending a notes off message. ( A long standing discussion in the world of sample lib fulltime users, which can be....enthusiastic)

The tiny gap between notes is a common user workflow fix for this, and the size of the tiny gap varies between sample libs, as to how they respond. (it basically ensures the note off is occurring before the note on arrives.)

I don't use Qtractor (using openoctave here), but if you have a ability to have that tiny gap between notes, with binding actions, or if you're precise enough with a mouse to vary the length of the note, then test this with your libs, and the problem may go away, or at least diminish. In openoctave, Chris built a set of actions to cope with this particular scenario, and it works well, more importantly, it doesn't slow down the flow of use and edit. And this set of bindings helps with VSL, Sonic Implants, MV, and a couple of others we've tested with. (Between us, we own these libs at least.)

Generically, most midi work benefits from having a gap between notes, and for string legatos built manually in particular. The instinct will be to overlap legato notes in strings, but with modern libs, the converse is true. The tiny gap allows the note to finish correctly, but the release component or "tail" of the note/gig will still sound into silence.
As always, your ears are the best judge of what you need to do to make this as human sounding as possible. You might find the gap can be a bit wider and still get the desired result.
If you're using sample lib constructed legato sequences (some libs do this), then as small a gap as possible may still give the desired result of correct note on/offs, and still "sound" correct. Experimentation is naturally encouraged. :) To give a direct comparison as an example, at 120 bpm 4/4, the gap may be the equivalent of 1/128, and be sufficient for a note off to trigger correctly, and the following note on to do the same.

It's often a good idea, based on my experience, to ensure, in a list editor (i don't know if Qtractor has one of these) that any midi data occurs in the correct time sequence. Having program changes, for example, with exactly the same point in the timeline as a note, can occasionally produce strange results, and the same is true for notes on/off with exactly the same time position. A quick edit in a list editor, to ensure the program change occurs just before the note is time well spent, and ensures correct playback. (and you'd be surprised how much of a difference this simple check makes, eliminating a lot of frustrating backtracking later)

If Qtractor doesn't have bindings for changing the length of notes by a "really tiny" bit, then i respectfully suggest you send an FR to Rui, the Qtractor developer. He's open to suggestions (and has been since i've known him) and provided you make a good case for the FR (which is fair), he is more likely to at least consider your worthy suggestion.


There may indeed be a bug in linuxsampler, but based on past experience, it could be more likely on the sequencer end, and/or alsa midi. (and as a linuxaudio dev told me some time ago, jack midi is sample accurate, and timestamps all midi data, alsa midi just processes whatever's thrown at it. That means if midi data occupies the exact moment in the timeline, then either one could be used. A few of use experimented with this some time ago, and indeed found the alsa midi "queuing" to be, at times, wayward. Rui's the real expert here, so maybe he can chip in with some added info to help debug this.) I've had the same challenges using commercial sequencers, and had to use the above workaround as a result.

The notes you're using, i assume, are 100% in length, as occupying the complete space between time events, i.e., grid lines. Maybe Rui would consider (as an addition to your Feature Request) to add a "99%" action, that when applied to a note, makes it 99% long, including re-adjusting the position of the note off message. So you'd do your inputting, be it live or step input, then select the note, and hit the "99% action", and it auto-adjusts the note length and note off position accordingly.

I write all this as a fulltime user over many years experience, with a variety of different sequencers. You may know much of this already, if so, i wish no offence, or seek to belittle you in any way, with what may seem like obvious info. There may be others reading this who don't have this knowledge just yet, and are seeking a solution to the same challenge.


Good Luck,

Alex.

Post Reply