Hi, does anybody know how or if I can get QMidiArp running on my Zynthian? I found a script in “/zynthian/zynthian-sys/scripts/recipes/pending/install_qmidiarp.sh” on the SD card but also a quite different script in the https://github.com/dcoredump/zynthian-recipe repo. Are any of these usable and how?
Hi @jgeisler0303,
I made the script in the zynthian-recipe repository more than one year ago. I tried to use qmidiarp as LV2 plugin inside MOD-UI. At that time the whole thing worked, but had a big disadvantage: The patterns are not editable. You could only edit them directly in the LV2 metadata. Unfortunately MOD-UI does not offer an upload interface. That’s IMHO why it’s not usable right now.
Regards, Holger
1 Like
Thanks for the quick reply. I saw your teaser post but were not sure you are the owner of the github repo.
I’m quite new to all this. Building a Zynthian right now. What language is the hardware UI written in? I dream of a simple step sequencer (for drum patterns and bass lines) and maybe an arpeggiator on the zynthian touch screen. No extra hardware, no PC, just a minimal Zynthian box 
Maybe I could try to fulfill that dream myself. Do you think QMidiArp is a good starting point for this?
Cheers, Jens
Python with some C.
We’ve looked at various sequencers and there have been some very laudable solo attempts.
seq64 was one recent suggestion, At the end of the day it would want to be a purely midi device using the MIDI router, to drive generic zynthian bits and pieces.
Little effort in this sphere is rarely wasted!
Pull requests welcome!!
Hi @wyleu, do you mean this seq64: https://github.com/sauraen/seq64?
I actually like the UI of QMidiArp very much. And I think, the UI is separate from the engine. So, maybe its possible to rewrite the UI form the Zynthian “Window Manager” / Graphics Framework. Is The Zynthian UI written with the pygame library?
No sorry an easy mistake.
I mean this one .https://github.com/ahlstromcj/sequencer64
a re do of seq24
OK, I started to dig around a bit. Zynthian GUI is programmed using tkinter graphics tool kit which in turn runs in an X server. This server doesn’t have a window manager but that doesn’t mean that it cannot display more than one window. Theoretically the GUI could launch a new process like a super simple LV2 UI host which hides the the main GUI until it is closed e.g. by the back button.
QMidiArp already has a LV2 UI plugin that may fit on the small screen. If not, it might be feasible to make it more space saving. I think this would still be less work than re-implementing the UI in tkinter. Plus the minimal LV2 plugin host could be reused for other plugins that are small screen suitable.
I think I’m gonna do some more research into the workings of an LV2 ui plugin host.
2 Likes
Jalv.gtk already has the capability of showing a UI on desktop, I don’t know what it would take to get that displaying on the screen.
Yeah, I looked into jalv yesterday. Unfortunately the QMidiArp UI is written in Qt (Qt4, I think) and the jalv.qt host is somewhat experimental. I got an access violation when I tried to launch it with QMidiArp (on the raspi aswell as on my desktop PC). But Maybe that’s a starting point.
New windows can be started even from without the x server, e.g. from an ssh terminal. The command for this is env DISPLAY=:0 XAUTHORITY=/root/.Xauthority jalv.qt5 -s https://git.code.sf.net/p/qmidiarp/arp
Do you happen to know what LV2 host is used in Zynthian?
EDIT: writing this, I noticed that I ran QMidiArp with jalv.qt5 even though knowing it is Qt4. So I tried again. On the zynthian there is no jalv.qt4 installed. But on my PC it is. I found out that the access violation only comes when jack is running. Otherwise I get an equally cryptic error. This probably means a lot more debugging 
We use a slighty modified version of Jalv. Also mod-host when using the MOD-UI engine.
Regards,
Ah, yes, thanks @jofemodo. Just as your message came in I started to look at ps aux.
Is the modified jalv version in the zynthian repo?
Of course 
Some of my changes have been already merged in the master Jalv, but with modifications, so i’ve to refactorize some code in the engine …
Regards,
OK, so here is what I found: Jalv is a really versatile and powerful tool. It can dump communication between a plugin and its UI and read controller changes from the command line. It was easy to augment the capabilities and now I have a jalv version that can also dump messages to the UI even when there is no UI (in the case of QMidiArp this is the current sequencer pattern and the transport position). Also it will soon be able to read non-controll messages from the command line (in the case of QMidiArp this is necessary, because the UI sends a special message that it was started, and only after that the engine starts to send info).
Together with the already existing infrastructure of the zynthian UI (where LV2 plugins are started as a jalv process and communication is already running via the virtual command line (stdin and stdout)), I think I will rather augment this and reimplement the QMidiArp UI in python-tkinter. My original idea to start an already existing plugin-ui on-top of zynthian doesn’t occur to me too good anymore. Just some reasons: the original plugin-uis will probably be too big for the small zynthian screen, there would be a break in graphics-style, there would be no integration with the encoders and general input-infrastructure (back button etc.), I didn’t get the plugin-ui running in jalv.
On the QMidiArp sequencer side, things will be pretty straight forward, if only a little bit weird. The interaction with the UI is actually via mouse position and clicks. This means that the UI only displays the pattern and sends mouse clicks to the engine which then sends an altered pattern back for display. This will make re-implementation of the UI especially easy and one could even make some sort of etch-a-sketch interfaces using two encoders for moving the mouse and the select button for clicking it.
We’ll see. Next I will try to setup the emulation to start developing the new UI on my PC.
3 Likes
Sounds really good. I’d be quite happy with a nice big bunch of arp presets to choose from so i could squirt them out through the MIDI out to my arp-less hardware synths. Also I notice they also do a MIDI LFO which woud be great fun to send to CV params for both internal and external synths!