Has anyone managed to install the MidiHub Editor on a Raspberry pi 4? It works fine on my MacBook Pro but, as I’m using an RPi I’d like to get the Editor working on it as well.
Any help or advice will be greatly appreciated
1 Like
I did try out an ARM build of the Editor locally, it seems to work fine, I will get it published some time next week. 
4 Likes
Many thanks for getting back to me with such good news. I really do appreciate everyone’s efforts in getting out such a useful piece of kit, especially during such difficult times.
I do hope that you are all OK over there and wish you well from a really mad place.
best regards
1 Like
Yeah, we’re doing quite fine over here, hope you are too. 
Ok, here’s the AppImage for Raspberry Pi, it should run on OS images based on buster: MidihubEditor-arm_1.11.1.AppImage
You may run these commands in a terminal:
curl https://blokas.io/midihub/downloads/MidihubEditor-arm_1.11.1.AppImage -o MidihubEditor.AppImage
chmod +x MidihubEditor.AppImage
./MidihubEditor.AppImage
1 Like
This is great! I use my RPi as a USB hub, and now with the editor for it too I can leave it permanently connected to the midihub over USB and edit patches on the go. Testing now…
2 Likes
Hmm, trying to launch on my RaspPi I get this error, which I think is because I’m on an older install
/tmp/.mount_Midihu1jc6s1/usr/bin/midihub-editor: /lib/arm-linux-gnueabihf/libm.so.6: version
GLIBC_2.27' not found (required by /tmp/.mount_Midihu1jc6s1/usr/bin/midihub-editor) /tmp/.mount_Midihu1jc6s1/usr/bin/midihub-editor: /lib/arm-linux-gnueabihf/libc.so.6: versionGLIBC_2.28’ not found (required by /tmp/.mount_Midihu1jc6s1/usr/bin/…/lib/libQt5Network.so.5)
/tmp/.mount_Midihu1jc6s1/usr/bin/midihub-editor: /lib/arm-linux-gnueabihf/libc.so.6: versionGLIBC_2.28' not found (required by /tmp/.mount_Midihu1jc6s1/usr/bin/../lib/libQt5Core.so.5) /tmp/.mount_Midihu1jc6s1/usr/bin/midihub-editor: /lib/arm-linux-gnueabihf/libz.so.1: versionZLIB_1.2.9’ not found (required by /tmp/.mount_Midihu1jc6s1/usr/bin/…/lib/libpng16.so.16)
Yeah, it’s suggested to build AppImages on as old OS version as possible, but at this time I only had buster set up.
What is the output of lsb_release -a on your system?
Looks like I’m still on stretch:
pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.11 (stretch)
Release: 9.11
Codename: stretch
Ok, I’ll try and rebuild on stretch, hopefully tomorrow.
2 Likes
Or I can try to upgrade to Buster…should run all night!
Well, it’s easier for everyone if it runs at least one OS release before the latest.
I’ve just installed it on the latest distro with only one error message
"QXcbConnection: XCB error: 3 (BadWindow), sequence: 7668, resource id: 16780222, major code: 40 (TranslateCoords), minor code: 0 "
However, it seems to work fine on my RPi4… just a few tests before a coffee…
Many thanks for doing this
1 Like
I upgraded to the latest Buster distro off the website (flashed a new SD card) and the appimage works fine there and connects to the midihub on an RPi 3+. Accessing over VNC is workable for editing patches.
3 Likes
This build should work on stretch and newer:
curl https://blokas.io/midihub/downloads/MidihubEditor-arm_1.11.1_stretch.AppImage -o MidihubEditor.AppImage
chmod +x MidihubEditor.AppImage
./MidihubEditor.AppImage
up and running and the sun is out
many thanks
2 Likes
Okay, at long last found the time and energy to rearrange and rewire stuff in a way that enabled me to try this for real. The editor seems to work absolutely fine on Zynthian (rPi 3) over ssh -Y link over LAN, which solves an important part of the puzzle here, probably more than I initially realized it would. 
Million thanks for the rPi build @Giedrius!
1 Like
Good idea with the X tunneling. We should make a guide for everyone on how to do that. I also plan to update amidiauto, so it can handle more than one pair of ports from the device, so it could be used to automatically route USB MIDI controllers to Midihub.
1 Like
Yeah, getting those connections in place is one of the remaining missing pieces at the moment.
With Zynthian, there are some extra hurdles because it’s all based around Jack MIDI, and has it’s own MIDI router which merges MIDI traffic from all ports into basically one big Jack MIDI stream. It’s possible to disable ports from getting merged, allowing the connections to be managed “under the radar” of the Zynthian router, but doing this on the ALSA-side would leave Zynthian’s own synth/midi-functionality outside this whole setup, when you really want it routed through Midihub along with everything else. There’s a2jmidid running, but that works in the “wrong” direction in that it makes ALSA stuff available to JACK and not the other way around. I basically need jmidiauto, instead of amidiauto 
I suppose I’ll just whack up some Python script to handle it until a more sophisticated solution presents itself…
It’s all so maddeningly close-but-no-cigar in an absolutely amazingly convoluted way 
1 Like
I have a crontab script which I use to set up the USB MIDI routings on my Pi. It basically runs aconnect every minute to hook things together.
And for running the GUI on a Mac from the Pi I use XQuartz to run a X server on the Mac and then ssh -X runs nicely. Little bit of a lag over a fast local Wifi, but not too bad at all!
Another alternative could be using udev rules, as in this post:
What’s nice about udev and amidiauto is that they react to hardware change events, rather than running periodically. 
1 Like