Issue: Stuck MIDI notes #1341
Comments
|
After some more testing, I've determined that it's not the amount of time between the messages that's causing stuck notes, it's the order thy're recieved. It just happens that the Octatrack is more prone to send the noteoff and stop messages in the order that causes a stuck note on the Zynthian when I allow more time between starting and stopping, but I've been able to produce stuck notes regardless of timing. The determining factor is whether the stop message is sent before or after the noteoff. If the noteoff comes first then the Zynthian behaves as expected, if the stop comes first then I get a stuck note. Correct behavior:
Stuck note:
As I described in the bug report, I've never had a stuck note with any other piece of hardware I've used with the Octatrack since 2017 (which is quite a few different pieces, new and old) and I also get stuck notes on the Zynthian sometimes with other controllers regardless of whether transport messages are sent or not, so it's not inherently tied to the Octatrack itself or to transport messages only, but these two sequences of MIDI messages produce consistent, replicable behavior so it seems like a big clue. I've been monitoring MIDI from the Zynthian's THRU port for all tests, so it should be completely untouched by the Zynthian software. EDIT: it's also worth noting that while I was not sending clock from the Octatrack for these tests, in normal use I have it set to send clock continuously, even when its sequencer is stopped. So while the fact that I have experienced stuck notes while the Zynthian from the Octatrack's keys with its sequencer stopped means that the problem isn't tied specifically to transport messages, the fact that I have always had clock running means it could be tied directly to system realtime messages in general. Later this week when I have time I will try to figure out whether there's a correlation between whether or not a synth accepts clock (i.e. for LFO or arpeggiator sync) and whether or not it is prone to stuck notes. I have never experienced stuck notes with Fluidsynth of VL-Tone, for example, and I'm fairly confident that all of the synths that I HAVE experienced stuck notes with are those that can sync to clock. |
|
I've had at least some stuck notes with every external MIDI controller and synth module combo I've ever used, not just the Zynthian. I think the only solution to truly eliminate stuck notes is to just not use external MIDI controllers. Period. However, some are a lot worse than others, so it can probably be improved. I'm just saying that actually eliminating stuck notes is unlikely, so make sure you have a MIDI panic button mapped. |
|
I can't reproduce this in the lab with a script sending these MIDI commands to zynmidirouter input. (Same input as DIN-MIDI.) The timestamps in your screenshots are in hex but there are no units. I see a single unit of time between the 1/2 and between the 3/4 and 305 units of time between 2/3. I suspect they are ms. Sending messages with these ms timeoffset (or other, longer intervals) does not triggers the problem for me. Webconf shows the messages received in the same order as they are transmitted. |
|
The different order off messages is happenign in the Octatrack, sorry if that wasn't clear enough. I've submitted a ticket with them but I don't expect it to amount to anything since they haven't updated it in years. The reason it's relevant here is that, for me, the order that the note off and stop messages reach the Zynthian (from and Octatrack) is the one variable I've found that consistently leads to stuck notes and allowed me to replicate the issue consistently, but it's not the only thing that causes them and the Octatrack isn't the only device that I get stuck notes with. The source of the MIDI notes and the synth engine that they are routed to in the Zynthian influence how common stuck notes are but it has been hard for me to replicate them with any kind of predictability, that's why I didn't submit a ticket sooner. I think this is less a report of a specific bug and more a data gathering expedition to see if we can collectively figure out a common factor that would help mitigate or eliminate stuck notes. There were a few threads specifically about it back around 2019 and it has come up in other threads since then, but the whole thing is pretty nebulous and the old threads never gained any traction. https://discourse.zynthian.org/t/stuck-notes-w-dx7/3464 Another data point that might help narrow things down is that, for me at least, I have never experienced or been able to deliberately cause a stuck note with Fluid Synth. I rarely use the other standalone engines, but this evening or tomorrow I'll find some time to see if I can deliberately cause stuck notes with ZynAddSubFX or any of the others. It's totally plausible that only LV2 engines experience them. If I can get one of the standalone engines to stick at least it would rule that out. At some point in the next week my friend who uses a DIY Zynthian will be over to work on writing, I'll try to have him bring it and take some time to explore the stuck notes that he gets. He uses a Pi 4, no official hardware and only USB MIDI, whereas I'm using primarily DIN MIDI on official hardware with a Pi 5, but we both experience stuck notes. Between our two systems we pretty much rule out every variable on the hardware side. If there's any specific information you want me to collect or things you want me to try, please let me know. |
|
I've been having same issues the whole day. I'm using the Hapax as sequencer. Midi cable goes straight into the Zynthian (latest V5 batch, have it since last week and installed the updates). It's indeed very random as to when and which synth it happens with. After reboot the issue is gone (until its back). |
|
edit: there was a snapshot here with the issue, but eventually it turned out to be sustain pedal engaged, so not relevant here |
|
The original report was against current oram stable (2412.5). Has anyone tested against staging (oram) or testing (vangelis)? I can't seem to make this go wrong on my test machine here in the lab. [Edit] I just switched to oram stable 2512.5 and the first F4 note I played got stuck... [Edit] ...but that is because the snapshot has the sustain pedal asserted! |
|
Oh uhm.. My bad I guess. I'm very new to Zynthian. Will research it. BTW, OT perhaps, but my machine says 2409.4 is latest Oram stable, not 2412.5 (and I had just run the update again) |
|
I assembled mine in the first week of December last year and the stuck notes have been consistent across every stable version of the OS since then, So I guess that would be 2409.2. I reflashed my card when 2409.3 came out. |
|
It would be useful if someone who experiences this, check if the sustain pedal control in the affected engine is asserted during the fault state |
|
I can do that later tonight, but the way it behaves for me I don't expect that to be the problem. After a note gets stuck I can keep playing notes and they behave normally while the stuck note stays stuck. I'm pretty sure once a note is stuck playing the same note a second time (which sends a new note-off message and would be expected to unstick the stuck note) doesn't work but I haven't tested that carefully yet, I just tried it a couple times during a practice a few weeks ago and it didn't seem to work. The internal all-notes-off/panic button always works for me. |
|
I just checked the sustain status. Used the same method I described in my initial bug report to stick a note in Helm, opened up the MIDI Controllers parameter page and confirmed that the controller widget for sustain was still displaying "off." EDIT: while I was emailing with Elektron support earlier today I also realized that the reason the STOP and NOTE OFF messages in my screenshot have the same time stamp is probably because I was monitoring the DIN MIDI data stream through a USB MIDI interface. The USB 1ms frame rate is slower than the MIDI data rate so it's possible for the interface to receive more than one MIDI message during a single USB frame. Because MIDI data isn't timestamped, all MIDI messages that arrive during a single frame occur "simultaneously" as far as the computer is concerned. That's the reason why it's impossible for standard USB MIDI interfaces to achieve jitter lower than 1ms and I would assume it applies to the timestamp accuracy of MIDI-OX with a USB interface, too. I switched to an RTP-MIDI interface on my desktop because the MIDI timing with USB interfaces was always too loose for me; I won't have time until Thursday but I'll try to remember to check with that and see if the stop and note off messages from the Octatrack are still identical when I have finer resolution. If I find a timing difference maybe Riban's script will be able to give us reproduceable stuck notes if it's adjusted to reflect that. |
|
Elektron suport was able to replicate the message order issue that I've been using to reproduce stuck notes on the Zynthian. Here's a more accurate log of MIDI events from them that could be helpful for us. This is the sequence of MIDI messages that will cause a stuck note for me on the Zynthian 100% of the time (at least when using the snapshot I included with my original report) with accurately logged timing between the start/note-on and stop/note-off messages:
"For context I believe that the MIDI frame duration on the Octatrack is 15ms, which means that the messages is sent in two successive different frames. " |
|
I was able to reproduce my issue tonight using the attached midi file in loop for 1hour 40mins, externally through the DIN Plug to the V5 (pi4) on current oram stable. I was sending only Notes On and Off with Sustain pedal using only Pianoteq The loop was continuous and so no changes to the system during the running time and until the issue no XRUNs in the logs, once the issue was heard, I had lots of them, no temperature change - under 40C CPU at ca 50%. After restarting the zynthian service everything was normal again (no reboot was needed) Jan 29 21:05:28 zynthian startx[900]: WARNING:zynthian_autoconnect.cb_jack_xrun: Jack Audio XRUN! =>count: 150, delay: 305.0us I'll run the same test tomorrow via the USB and let you know, small steps, after that I'll move to vangelis. |
Describe the issue
Sometimes MIDI notes get stuck on. Some synth engines seem more prone to it than others but it isn't specific to any one of them, and doesn't correlate to CPU load - for example, I've never had it happen with Osirus/OsTIrus but it's fairly common with OB-XD and many others that are far less CPU intensive, and very common with Helm. Since it's easiest to reproduce with Helm that's what I'll use in my example.
To Reproduce
Steps to reproduce the behavior:
It's hard to narrow it down to any one scenario that causes it, but I am able to consistently replicate it using Helm and sequenced MIDI from my Octatrack. This is not the only thing that causes stuck notes for me but it's the only way so far that I've been able to easily, consistently replicate the problem.
Expected behavior
Note off messages received from an external device.
Actual behavior
Note off messages from external controllers are sometimes dropped, depending on variables including (but not limited to) duration and whether transport messages are also being received.
Additional context
The attached zip includes a standard MIDI file that were recorded from the MIDI thru on the Zynthian while I was preparing this. They are only useful as a timing reference - playing them back into the Zynthian does NOT produce stuck notes since they don't contain the transport messages (I haven't found a way to record system realtime messages, unfortunately). The first two notes in the file didn't produced stuck notes on the Zynthian, regardless of whether it was also sent transport messages. The second two notes in the file didn't produce stuck notes if no transport messages were sent but DID consistently produce stuck notes when transport messages were sent. Because I have also experienced stuck notes without any transport messages I don't believe they are the root cause, but the fact that I can consistently control whether or not notes stick through a combination of note duration and presence/absence of transport messages.
I also included a MIDI-OX screenshot showing an unfiltered MIDI stream that produces a stuck note.
Zynthian stuck notes.zip
Configuration
Hardware
System
MIDI & UI
Software
The text was updated successfully, but these errors were encountered: