This isn’t a thread about something on the new Vangelis not working, it’s a thread about Zynthian solving a problem and I’d like to find out why. Maybe somebody has a few hints where I could start to look or maybe this has also happened to somebody else. For the record I’m on Ubuntu 24.04 kernel 7.0 (stock) pipewire, running Bitwig Studio.
The situation: I have an Oxi Coral module that has a TRS MIDI in. When trying to play a MIDI clip from Bitwig through either a Scarlett16i16 or an ESI M4Uex the module behaves in a strange way, dropping most notes, switching engines, the notes that are played are not in time at all.
When a controller Keyboard is plugged directly into it there’s not problem, it can be played normally.
Ofc firmware on the Coral is the newest and I have a new revision (V3) that has an old V1 problem with resistors near the MIDI in solved.
Then I tried this setup:
Bitwig->USB MIDI to Zynthian->track that just forwards USB MIDI to MIDI out->Coral
this works without a flaw. Same cables, same track configuration in Bitwig, everything is the same except the MIDI out port of the instrument is set to Zynthian MIDI.
Now what does the Zynthian do to the MIDI signal coming from my PC? Could this be replicated in Ubuntu Linux or is it likely to be a hardware incompatibility that can’t be changed?
My buffer size in Ubuntu is set to 512, SR 48kHz.
1 Like
Curious! Good to know that zynthian behaves nicely as a MIDI bridge in this case.
Regarding the reasons because the other 2 devices (Scarlet16, ESI M4Uex) don’t work as they should, you would need to compare MIDI logs including timing to see the difference, etc.
It’s a big buffer size. You will have a big latency with this. But what you describe above doesn’t look like a latency problem.
Regards
1 Like
Why not? If the latency is too high, buffered MIDI events may occur at the wrong time. If sent as „immediately" to ALSA they may even occur in the wrong rhythm.
I encountered similar behaviour when I wanted to write a MIDI filter with JUCE. At that time I found out, that JUCE always assumed that its MIDI queues are used in real time and may drop or misplace events when they are used differently.
But lets go back to @OutOfCheese
Your description skips some important facts: What exactly is the chain “USB MIDI to Zynthian”? And how does it differ from the other setup?
You may have some problems with the current supply for your MIDI cable. To explain this, we need some facts:
- MIDI cables close a current loop (they do not provide a voltage connection). Some MIDI devices skip the current regulator and place a simple resistor instead. Then instead of compensating for the resistance of the MIDI cable the resistor adds to it. As a result at the receiving end a poor signal arrives. Try a short cable with a large cross section to rule it out.
- Similarly on the receiving end an optocoupler is mandatory. Some equipment skips it. This might also have strange effects to the signal.
- The sending device might not provide enough current to drive the optocoupler at the receiving end. I have simple keyboard that cannot drive the input of my Korg M1. However if I send the MIDI signal through my Laptop (MIDI ⇒ MIDISport ⇒ USB ⇒ Laptop ⇒ USB ⇒ MIDISport ⇒ MIDI) or through an organ pedal controller from Doepfner, the MIDI events are recognised by the Synthesizer.
In short: passing the MIDI signal through Zynthian might boost the signal an an analogue manner, effectively.
Last but not least, you may face a digital driver problem.
Summary: I guess, you probably face a driver problem: Either a digital driver Problem or Problem with the current driver.
2 Likes
@keinstein Hi, thanks for your answer. I’ll try to be as brief but precise as I can.
USB MIDI to Zynthian means I have the Zynthian connected by its USB-B port to the computer, providing a MIDI connection from the PC to Zynthian via USB. This is then directly forwarded to the Zynthians DIN5 MIDI out port via an empty MIDI chain.
Both the Scarlett 16i16 and the ESI M4U ex are both class compliant interfaces, I don’t use a special driver for those (also I’m on Ubuntu so most of the time there’s no drivers for devices, with a few exceptions).
The Coral revision V3 claims to both support 3.3V and 5V sources. I did some limited research and I believe (but didn’t verify myself yet) both my interfaces use 5V sources to drive the current, as do the Zynthian and the arturia minilab 3. In the V1 version of the Coral there were problems with 3.3V sources due to some resistor having the wrong value, but that’s claimed to be resolved now. Since I also don’t have midi gear with 3.3V sources this shouldn’t be the issue.
The coral has its own (shared) power supply (behringer CP1A) with still a lot of reserves available (I only have few modules connected).
I’m working on an “experiment” to compare raw midi data at different points on different paths from my computer to my gear but atm my job doesn’t leave me with a lot of time, so sadly progress is slow.
In addition I’ll try to get my hands on an oscilloscope to check the signals of the interfaces, if they’re really 5V and if the 5mA current loop works as it’s supposed to (both interfaces have their own power supply, ie not powered by the PCs USB ports, so I don’t expect too much from that side).
As to the latency - the Zynthian receives the exact same MIDI clips the interfaces receive, so why wouldn’t Zynthian also forward latency problems to the Coral? But that’s easy to check, I can just lower the buffer size on my PC and see if things change.
1 Like
OK. Now I understand: You are using the Zynthian as USB MIDI interface similar to MIDISport 1x1.
You claim that all three devices use the same class compliant USB sound driver. The most notable difference is that the drivers in Linux are organised by Protocol (using Quirks to adapt to specialities) while Windows organises them by market names. Most important drivers are included in the Linux kernel. And the distribution takes care of activating them, so you don’t have to worry about them.
The command lsmod will tell you which modules are loaded (something like drivers).
You could save its output via lsmod >filename into a file called ‘filename’. So changing ‘filename’ to something different you can check whether the devices use the same driver:
• Plug in a device and run lsmod >filename1
• Plug in a different device and run lsmod filename2
Then your can run diff filename1 filename2 to check whether there are differences. This command shows only the differences of the files.
The devices use the same drivers (not the same quirks) if the outputs of lsmod don’t differ.
Do you connect the MIDI devices via ALSA, JACK or OSS to Bitwig Studio? If the interface is different, try to use the same interface. Since Pipewire is based on JACK and can emulate JACK, you have at least two ways to interface MIDI devices (OSS is a little bit exotic for Linux).
Originally MIDI required a current driver for the MIDI sender. A fast scanning of the 2014 update available at midi.org for a registration didn’t reveal this requirement. This update provides at least resistor values as current limiters. When they are used and your MIDI cables are less than 15 m, there should be no problem for the receiving opto insulator. The difference between 3V3 and 5V is defined to be on the sender side, but not on the receiver side.
You can also use the oscilloscope in order to watch the temporal distribution of MIDI events. And you can measure the actual current when you measure the voltage drop over the input resistor of the receiver. This resistor must be 220 Ω so a voltage drop of 0.005 mA * 220 V/A = 1.1 V should occur. Check that the resistor has the right value. If the voltage is lower, you have a problem with the sender.
Regards,
Keinstein
3 Likes