DIN MIDI problems with RPi5 (RESOLVED)

Using Zynthian
1

While upgrading my V4 with an RPi5 (Zynthian 4 upgraded with Raspberry pi 5! - #22 by ricard) I read various worrying comments such as this one MIDI issues with RPi5 and Pisound card - #2 by HansDampf about DIN MIDI not working on the RPi5. So far I’ve only been using my RPi5 based Zynthian with my master keyboard with USB, but today I tried DIN MIDI with my sequencer, and there was utter silence. No MIDI indicator in the Zynthian display, and no MIDI events coming through. The MIDI IN led on the back was flashing nicely though so it wasn’t a cabling issue.

A bit of research brought me to this:
https://forums.raspberrypi.com/viewtopic.php?t=385906, including a link to a patch for the most recent 6.12 kernel, which updates the midi-uart0-pi5.dtb file (and the corresponding files for the other potential UARTs). Now, Zynthian uses the allegedly more stable 6.6 LTS kernel, and since I have already compiled a custom kernel (with a patch in order to use with another one of my master keyboard, the CME UF6), I took the patch (overlay: Rework/fix the Pi 5 MIDI UART overlays · raspberrypi/linux@149c85c · GitHub) and applied it, rebulit the .dtb files, and copied the relevant .dtb files to the SD card (to /bootfs/overlays (or /boot/overlays when mounted in Zynthian)). Hey presto, DIN MIDI is now working! So this was definitely the solution.

Indeed, @HansDampf also noted the aforementioned thread (although the link in his post is completely different for some reason), and has also tried a different kernel, albeit 6.12.25, which solved his problems (Stuck/Hanging Notes - #19 by HansDampf). The thread mentions it working with some 6.12 versions and not with others.

Now, I don’t know if this is a problem with the original kernel included with the latest oram image (and I don’t have a spare SD card to experiment with at the moment); it would seem strange if there’s a DIN MIDI problem with the RPi5 Zynthian V5.1 as there must be quite a few RPi5 Zynthian users by now, but I don’t think Zynthian uses a custom kernel, does it? At any rate, I’ve attached the midi-uart0-pi5.dtbo file from the above patch in case it helps anyone else. It has been compiled together with a 6.6.78 kernel but I think it will work on a variety of kernel versions as it’s not code, just a device tree overlay.

EDIT: Something is amiss here, I just noted that /boot/config.txt does not even contain a reference to midi-uart0-pi5.dtbo, only to midi-uart0.dtbo (which itself seems wrong) so replacing the former can not make a difference. Need to research this some more.

EDIT2: No, it’s definitely midi-uart0-pi5.dtbo that is the culprit. Replacing just this file with the original version causes DIN MIDI to stop working; adding it back brings it back again. I still cannot understand when it gets pulled in though, when looking at the config.txt file. - Looking at /sys/firmware/devicetree/base/clocks, midiclock_0 specified in the overlay is there, as well as the specified click-div and clock-mult from the devicetree overlay. So it’s definitely been brought in, somehow.

midi-uart0-pi5.dtbo (808 Bytes)

1 Like
2

Thanks @ricard !

The DTBO solves the problem with MIDI-DIN5. I will release a hot-fix ASAP.

I hope this also fixes the problems with hanging notes that i always suspected were caused by clocking issues.

The best,

1 Like
3

Damn! The kernel 6.12 should be already installed in ZynthianOS but it’s not, and i didn’t notice!

Cuirously …
We was using “apt-get” in the update scripts, and it was not updating the kernel packages:

The following packages have been kept back:
  firmware-libertas firmware-misc-nonfree libcamera-ipa linux-headers-rpi-2712 linux-headers-rpi-v8 linux-image-rpi-2712 linux-image-rpi-v8 rpicam-apps-lite zynaddsubfx zynaddsubfx-data zynaddsubfx-lv2
0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.

When using “apt”, the kernel packages are installed normally and kernel 6.12 is then installed.
I’m working on fixing this ASAP. We will release a new stable release with the fix and will force a kernel upgrade on all branches, including stable, but first we have to test there is no hidden problems with the upgrade.

Regards,

1 Like
4

The fix is in Vangelis for testing.

Regards,

4 Likes
5

I think to remember reading on a raspi forum that Pi5 Os interprets midi-uart.dtbo as midi-uart-pi5.dtbo and suggested just typing midi-uart-dtbo and the system if you write …-pi5.dtbo interpret it as …uart.dtbo. this just for the config.txt file references side of things.

PS: note, I have no idea under Zynthian Os if this is true also, as the rpi also don’t need uart-pi5 and automatically points to uart-pi5.dtbo…

1 Like
6

Well, ZynthianOS is built on the Raspberry OS, so same mechanism would certainly apply. Your recollection sparked me to research this some more (with the help of MS Copilot, no less), which eventually landed me here: https://www.raspberrypi.com/documentation/computers/configuration.html#part2.2.10 .

So, simply, there is a mechanism via /boot/overlays/overlay_map.dtb, which maps overlays to others for specific platforms. So for instance for midi-uart0.dts, the source file overlay_map.dts says:

        midi-uart0 {
                bcm2835;
                bcm2711;
                bcm2712 = "midi-uart0-pi5";
        };      
        
        midi-uart0-pi5 {
                bcm2712;
        };

basically saying that if midi-uart0 is requested on an RPi5 (which uses the bcm2712 chip) to load midi-uart-pi5 instead.

7

I updated Zynthian to Vangelis (testing) version
My sq64 is connected only through DIN MIDI.
Ssh in, from web-browser I did the update and reboot, then checked
Midi log. Only one when replugging the midi cable it appeared a SYS STOP, or something, then nothing else…
Sq64 Midi Out TX is enabled, it’s the same patch the I used to lay the 007 DX snapshot.

I’m on Vangelis.
The Webcon sees my new Domoshop hat (it says Zynthian compatible, it has the 23017 chip presoldered, and the midi in out in TRS) . The Web tool confirm it’s present, at least it sees the mcp230xx at 0x21 address.

Anyway, I can’t get the midi DIN working at this moment.
Not sure what I’m doing wrong.
For the Encoders and 203170 part I’ll stick to proper threads. tnx,

8

Just did a quick test with my RPi5 based V4. Flashed the latest oram, then updated to vangelis (I couldn’t find a completed vangelis image, but perhaps it wouldn’t be worth it since there are always new updates coming, so since you need to upgrade anyway, you might as well start with oram and switch versions once Zynthian has booted).

  • DIN MIDI works
  • Linux kernel is 6.12 (so my CME UF6 via USB now works out of the box. Yeay! :slight_smile: )

I understand this doesn’t help your issues @bambalaya, and it’s nothing new to @jofemodo, but I thought I’d just verify it independently for completeness. (Plus I want to try out the Novachord emulator which is only in vangelis for now…).

9

Thanks @ricard for validating that DIN-5 MIDI is now working in testing (Vangelis). Did you do an exhaustive test? The issue with missed events can be slightly random.

We don’t create images for the testing branch, one the stable and staging (Oram) when we are preparing for a new release. Anyone can switch to testing (Valngelis) or another dev branch, at their own risk!

10

Well, not terribly extensive, played for a couple of minutes, adding pitchbend, CC and sysex events. Didn’t notice anything strange at all, FWIW.

When the wrong overlay was added in oram, it wouldn’t work at all for me, although some people seem to have reported some events getting through (from what I understand, the problem is that the baudrate was wrong, so if one is lucky, some stream of bits at the wrong baudrate could get interpreted as something useful).

(The whole baudrate thing seems bizarre BTW, what the overlay does is change the clock source of the UART so that when the UART thinks it’s doing 38400 it’s actually doing 31250 (the MIDI baudrate). I’m guessing this is because the tools and/or infrastructure for setting baudrate can only set standard baudrates (like 9600, 19200 and 38400 etc), so instead of making changes on that side, the UART source clock is set up “incorrectly” so that setting a baudrate of 38400 actually sets a baudrate of 31250).

11

Yes, the whole baud thing is ridiculous. We are decades past the concept of discrete bitrates but it is deeply embedded in the kernel for serial ports. I thought this had been changed, allowing non-standard baud to be set but I may be mistaken or the stack on which tty-midi depends may not have been changed or our version of tty-midi (which is the mod branch) doesn’t include the change. Anyway, the new overlay does the job to manipulate the RP1 frequency to give us reliable MIDI - yay!

When I tried to look at this on a scope earlier this year I saw no output and didn’t have time to investigate further. I’ve downloaded the latest image so will try this as well as validating another type of uSD card. But I first need to save the work I am doing in a dev branch… and do life!

12

I reflashed this image, I tested Vangelis before but system crashed, so I had to reflash anyway.
Should I update to Vangelis again?? Or better wait for an Oram update??

13

I don’t know when Oram will next be updated. There should be no reason for a crash when switching to vangelis. Indeed, I don’t really understand what you mean by ‘crash’. It is a rather vague word for such a complex stack of software. It usually refers to a single bit of software failing with an exception.

14

During the update it didn’t shut down and didn’t reboot, I then turned power off
and upon reboot the screen remained black and webconf couldn’t log in.
Ineither have an idea of what could have gone wrong… I was trying to test different
tasting branches all one after the other… I went Vangelis, then Zynbleton, then Oram 25… then Oram stable… and then it hang upon reboot… maybe the bootloader went corrupt, idk.
Anyway got the new image and reupdated to Vangelis again with no errors now.
I have i2c enabled in raspi config
I reset hifiberry-dacplus dtoverlay with,slave option
changed the 23017 encoders so only one should be working
updated via webconfig

All seems good for the at sys level.
Only running pinctrl in terminal I couldn’t see any pins assigned to interrupts.
I wanted to post a screen capture of that, but otherwise sys log don’t
report any particular errors.

15

:grinning: this explains why a “loopback test” of the MIDI ports worked, as did connection to other V5.1ish Zynthians work very well. I’ve never tested them with other devices, nor checked the baud rate. Whoopsie… :rofl:

PS: This also shines a light onto the question about how much this classic MIDI is really used nowadys, because there have been few complaints about the issue for the stretch of time V5.1 is in the wild now.

16

The issue was identified fairly early and I suspect many of those who use DIN MIDI read that post and hence were aware of the issue and day quietly awaiting resolution.

They are a lot of DIN MIDI devices or there (many in my studio!) possibly due to how well engineered electronic instruments were in the 1980’s.

17

USB Midi is really a nightmare of problems, waiting for the perfect storm to happen…
I fear the dready USB Midi only devices and avoid them like cancer-infected viruses at at all costs…

Roland released the first boutiques with both Midi Din and USb Midi… Usb Midi stopped working on Mac OS after Big Sur and Windows it never really worked in the first place…
So by chance there is now Midi Din in those machines like the Jp-08…

Uds-Midi latency? It’s the worst thing a musician that needs to sync various hardware can think of… you can use it in a studio with delay compensation but for live it’s a chain of 50+ms delays that is utterly unusable.

Other non Usb-compliant Midi devices like the NitfyCase and a whole bunch of other Korg and Roland Gear, just to name a few… are on the same obsolescence bandwagon…
a single Usb protocol change and all goes to the high seas…

The whole Baud rate shebang, and complete disinterest at raspberry community is telling a lot yes, very few people cares about it, my ttymidi thread has gone basically silent on raspi forum… as it’s better to not investigate how hundreds of screwed libraries won’t be rewritten from scratch because by next month some folks might decide to change again architecture, without testing for compatibility as they did with the Pi5 release and don’t want anyone to ask anything about it, just consume and be happy there is Usb Midi at least…

I will probably return mi Midi hat and abandon this project in a week or so.
My life isn’t worth months of losing hairs.
It’s been one month of being mocked and ridiculed for something the bloody hell
I should have known by birth.

What if I wanted to make a Midi through- raspi hybrid device?
Midi Uart is essential… idk, I feel lucky this discourse exist at least someone
understand… over there it’s freezing cold… Usb midi delay falls over dead ears over there.
There is no simpathy for the devil.

18

It comes down to workflow. I have equipment ranging from over 40 years, the usb stuff is just way easier to deal with, to the point the old stuff I use usb-midi adaptors with. Rather than have chains of instruments driven off midi sequencers, I’d much rather record it and play it as a backing track. More reliable, less to transport. Less power plugs.

19

I ve found QMIDInet over Wired Ethernet, pretty good but to be fair I haven’t given it a proper Engineering appraisal, but it seems to make the right noises at the right times.

1 Like
20

No, fuk Kork, Roland, and their prorpietary Usb Midi drivers,
DOn’t justify that stuff just bc it’s useful…
Good for you, but it’s a virus and I use it too but don’t trust it.
I wont change my mind.

All this mess with the Pi5 should have never happened in the first place if those guys wouls have simply done the
most basic of the tests.
They sold us an unfinished product and its up to the community fix it.

As other said, I have old synths that only works with old Midi Din.
I have a PC 32 bit with Win Xp just for one of them because
the “Vst” part of it and only worked with XP.
I too like not having to deal with cables, but reality is a mess,
so at least DIN Midi is a safe harbour for most of this stuff