I don’t need to be playing heavily. Simple single notes can trigger the stuck notes.
Can’t say I 've seen it. The main board I do this from is a Roland A88 which is a saintly old adherer to everything standard. . . .
I’ll set it up an see what I get when net I have the opportunity of getting the rig near each other.
Have you disabled your pihole?
2 Likes
I have the Zynthian connected to the home network with wi-fi and the minimal Zynthian connected with a network cable to a wi-fi router. Apart from a few insignificant clicks it works great. Now out of curiosity I want to try to connect the two Zynthians with a network cable between them.
Defo avoid WiFi. You WILL lose messages.
I just connected two Zynths with a direct cable and it still loses messages with hanging notes.
I’ll try it later and tell you how it went
Is there a MIDI test signal suite defined anywhere…?
This isn’t a MIDI issue. The UDP messages are going missing. Likely issues:
- The message does not leave the source device - most unlikely
- The message is being lost in transit - could happen with some types of switch / router but unlikely with direct wired connection
- UDP packet not being received - unlikely
- UDP packet not being passed up the stack - possible
- Conversion from UDP to MIDI failing - possible
- qmidinet failing to decode / despatch the MIDI - possible
- Zynthian losing the message - possible
It feels most likely that the issue is in qmidinet. I just used tcpdump to prove that the TCP/UDP stack is receiving the UDP packet when Zynthian misses a note.
I see an error logged by qmidinet when the error occurs:
jack_midi_event_reserve: time parameter is out of range (256 >= 256)
[Edit] It looks like qmidinet is requesting jack add an event at position 256 which is larger than the buffer size. I wonder if there is a 0/1 indexing issue…
Yep! Looks like a bug in qmidinet. I have applied a quick fix and am testing. If it is good I will submit upstream and update our version with the fix.
The fix looks good but I need to look closer at what the author is doing - it looks wrong at first glance. I will check it later when I have more time.
2 Likes
@wyleu mentioned an issue with autorouting that he thought was fixed but I have found that the route to / from qmidinet is not made automatically and needs a nudge, e.g. add/remove an synth chain. I understand the reason for this but don’t have a solution in my head yet. The routing graph is updated when configuration changes, e.g. add/remove a chain and there is a background check for change of MIDI interfaces that triggers an update of the routing graph but if qmidinet is enabled there is no change of MIDI source / destination so it may miss setting up a route. (I haven’t thought that through thoroughly and it doesn’t sound quite right but I have certainly had a lot of incidents today where I have had to trigger an update of the routing graph by adding or removing a synth chain but I have also been under the bonnet with my scalpel so triggering unusual behaviour.)
Agreed, but it would be useful to have a MIDI test set that could be both generated and recognised witihn the Zynthian infrastructure so go/no go testing could be easily accomplished.
The alternative is the use of random test data sets, which whilst they can be optomised for a particular fault are better integrated into a suite so we can perform regression testing.
I have submitted an upstream ticket for the stuck MIDI notes. I reviewed the code and the quick fix I made yesterday was wrong. The actual issue is that qmidinet adds one period of latency and processes events before the current processing period but was including events at the start of the current processing period. These were consequently bounds checked and moved to the start of the output buffer resulting in the message having the potential of being sent out of order due to it being moved a whole period back in time. This could then result in the note-off arriving before the note-on event, however this may never have happened due to jack constraints about message timing and the whole buffer might have been dumped, e.g. the note on may have been received first then all messages scheduled to arrive before but actually arriving later may have been ignored. Either way, the fix was simple and a patch has been sent upstream.
We now need to update our instance in Zynthain (which is the one in the Buster repository and quite old) to the latest stable with this patch applied. I suggest we wait a few days to see if upstream accept the patch and release an update.
2 Likes
With the second Zynthian connected to the home network router (with cable) and the first connected to the same network with wi-fi, it works well even with piano parts full of notes … The only thing is that when I turn on the second Zynthian I have to unflag the QmidiNet box and re-flag it… otherwise it won’t start… for the rest it seems to me that it works well… apart from the slightest clicks probably due to the wi-fi.
Unlikely to be due to MIDI over wifi. Clicks on audio are often an indication of xruns which may occur anywhere in the sound system including places that Zynthian doesn’t look. You can get xruns without zynthian indicating on the UI. If you are passing audio over wifi then it may be the cause of your clicks.
That said, it is unwise to use wifi for qmidinet. WIFI is by design an unreliable transport and qmidinet has no detection of delivery. Combine the two and you get a promise for lost messages and latency will vary dramatically giving woefully poor jitter on the MIDI. There are more reliable transports but there are conflicting requirements in reliable delivery and low latency. It is possible but complex.
2 Likes
I’m just experimenting… I don’t think it will be something I will use a lot… but I like trying to understand… Thanks Riban
Instead, it would be interesting to have an Arduino (it costs much less) with the commands (4 encoders) and a display to control the Zynthian with Qmidinet positioned near the PC that records or the mixer in case of live
You could do that but it feels a bit abstract and convoluted to build a hardware interface that sends MIDI over IP to Zynthian that then maps the MIDI to CUIA (which is all implemented already). It would seem better to build the hardware controller to send OSC messages to directly control CUIA with the added flexibility of more control and parameter passing as well as the reduced overhead of MIDI/CUIA mapping. If you have build a box that has a network interface with IP stack then it is a small step to use an OSC library instead of a MIDI library… at least that is how my mind works! 
1 Like
Sorry Riban… I explained myself badly… as always…
Having had experience with Live and now having experience with DAWs, I was wondering if it was possible to have the Zynthian near to the instruments it is connected to (DAW or Mixer), when the keyboard is on a stage or even a few meters away from the PC with DAW … the keyboard is connected to the DAW with a usb cable and the DAW controls the Zynthian via MIDI … but from afar it would be (for me) interesting to control the Zynthian as if it were on the piano without having a pc with UI … A small display and 4 encoders to change sound or change levels without getting up from the piano… I hope I explained myself better…
You seem to be describing something that @wyleu has been harping on about for some time. A remote control for Zynthian that kinda looks like a Zynthian but is just the control panel. We have lots of efforts from lots of contributors over the years with a wide range of solutions, many of which are hidden in this forum. These include: OSC control from tablet and rotary encoders and switches sending MIDI amongst others. What will really open up opportunities is when we get a proper API with true separation of the UI from the core.
3 Likes
I have no doubts about your abilities.