Hi @MrBroccoli, I was looking into one of these (superlooper is begging for a foot controller!), and remembered this thread. Did you got it to work in the end, via Bluetooth or even just via USB cable? (Assuming zynthian can power and interface midi with the usb cable, or is that not the case?)
Sorry, I got sidetracked with other things and have not got back to this yet.
Nothing to be sorry about!
According to this, midi can flow through USB and also using the TRS (sacrificing an expression pedal). I think I’ll just go for one and report back (might take a while from AliExpress). Stay tuned!
2 Likes
Finally, I got the (very small, exactly what I wanted for my limited floor space) Chocolate / M-VAVE foot controller. Only did a few experiments, and the answer to my question seems to be negative - USB is limited to upgrading its firmware and to recharge the device.
Didn’t try bluetooth into Zynthian directly (maybe next weekend). But it’s easy to configure from the App (tried the desktop Mac app as well as Android, both connected with no issues and respond well), so my Ableton Live seems to like that. My thinking is that this is a good fallback as I can then send the MIDI signal to Zynthian, in case I can’t get it to work with Zynthian on its own.
Also an option would be to use the Pedal port as a TRS MIDI out (but then I’d loose the Pedal support that is useful). I’ll have a think / experiment and balance this to the fact that having Chocolat linked to Ableton allows me to use it with more than just the Zynthian.
First impression is positive though - considering how cheap it is.
Next post shall be once I can get SuperLooper to respond to it and actually use it to, well, play musi - eerm, sounds!
And i got some time to fool around this cute foot controller. I decided to give it a go with the actual intended device functionality, i.e., bluetooth MIDI (directly to Zynthian). I followed the instructions @gonzoB sent at the start of this thread, and:
- The bluetooth service, pairing process, all went as smoothly as I could expect - from the terminal, that is. Would be fantastic to have this done in a nice UI on Zynthian itself, but I’d live with this. That is if it weren’t for…
- The MIDI connection we do with ‘aconnect port 14’ seems to get removed after either a time period (a few minutes, but i’m finding this unlikely, as the time varies) or some midi notes/CC sent or something I keep doing while playing on a Dexed on channel 1 and that foot controller.
@gonzoB, you mentioned:
Unfortunately, it doesn’t re-connect the MIDI port on re-boot.
That’s unfortunate, but I don’t even get that far 
Any suggestions on what might be happening? As for the reconnection, I appreciate the bluetooth device would need to be on when Zynthian boots otherwise an automatic startup script wouldn’t work. Which makes me wonder, how useful would it be to have scripts launched via a small menu, maybe on the admin screen, configurable in the web config? Going one step further, to assign them to a CUIA action, so it can be triggered in whatever way the Zynthian player feels comfortable with. So initial question - is this already possible, and I haven’t stumbled upon it yet?
Last, I do hear annoying stops when recording, too often to let me make more than a few bars. I’ll keep trying for a bit to see if it’s power related or something else. But I just found out the actual recordings don’t have such pauses, it keeps going - but makes it almost impossible to keep track. Anyway, I believe I’m still due a 
, so here goes something from a total amateur at keys (proving the gapless audio).
Hi.
Well, the thing to do is when it stops do a ‘aconnect -l’ to see if the device is still a) connected to the OS, and b) routed to port 14.
If the connection has dropped out (the device is no-longer seen by the OS), then you need to find out why - signal interference, bad connections, etc.
If it were me (I don’t have a zynth any more), I would write a little script which runs every few seconds to
a) check if the device and routing is OK - if yes, do nothing
b) if no, check to see if the device is still connected, then re-make the routing
c) if the device is no-longer there, then run a BT check to see if it is available, but not connected, and re-do the connection.
Of course, this would also fix the problem on start-up, and you wouldn’t need to have the BT device turned on at boot time. It will however mean that you may lose the device for a few seconds until the script re-makes the connection.
Hope that helps.
Gonzo
Thanks @gonzoB. It seems to be connected, just not routed anymore - so much so that re-doing a ‘aconnect 129 14’ gets it back straightaway. So your idea of that watchdog script would do the trick - except it would make the controller unusable for (near to) real time play such as with superlooper.
I’ll try and find out the cause for the un-routing on my next venture with Zynthian (hopefuly by this weekend or before). Otherwise, I’ll try to use it via cable. Or as per my fall-back idea, via Ableton!
Zynthian has an auto-router module which will route and unroute based on its expected graph. If you manually route something it may be unrouted by autorouter at some point.
If you enable the MIDI input within webconf and configure it to route then it should get routed by autorouter.
@riban, that would be ideal. The pairing of the controller via bluetooth seems to have stuck between reboots, I just need to turn Zynthian on then turn Chocolat on (yay!).
Now it’s just getting that routing puzzle piece sorted. But I’m a bit stuck! Was I supposed to see the device show up in the webconf? here’s what I have, and the output of aconnect -l (after I run the ‘aconnect 129 14’):
I’ve refreshed webconf, and still can’t see the FootCtrl anywhere in that checkbox lists. Could that be defined in a script I could change? (Or, am I looking in the wrong place in webconf for this?)
By the way - thanks gents, regardless of final outcome on this, I learn a lot in this forum - and have fun too!
Hi
I just took a look at this. (I don’t have any MIDI over Bluetooth devices so I had to build one first to test!) The above instructions to connect a BLE MIDI device to Zynthian adds an ALSA seq client but no ALSA raw MIDI device. Zynthian uses ALSA raw MIDI devices hence it does not see the BLE MIDI input. I will see if there is a solution but anyone else with knowledge of this, please pipe in.
I did try changing Zynthian to use -X seq instead of -X raw in its jackd configuration but the port names are not recognised properly and hence cannot be selected. (There are other considerations to changing from raw devices so its not a desirable solution.) I think the issue may be that the ALSA client is created as a userspace client and there is never an ALSA device in place. I don’t know if it is possible to implement the interface as a raw ALSA device. More research required.
[Edit] I tried using snd_virmidi virtual midi driver which works but creates too many MIDI ports (4 x 16 - can be reduces to 1 x 16 with option midi_devs=1 but still too many). But you can use the MIDI Thur connector, e.g. aconnect 'UD-BT01':'UD-BT01 Bluetooth' 'Midi Through':'Midi Through Port-0'. This will route the BLE input to MIDI thru which appears as a Zynthian MIDI input in webconf.
My tests with my new BLE device show it reconnects automatically when Zynthian boots or the BLE device starts but the alsa route would need to be remade. There may be a way to do this automatically. more research…
I’ve done a bit more work on this today. I can detect a bluetooth serial port connection (which is how BLE MIDI is presented) and run a script to route the MIDI but have not yet figured out how to detect the name of the new MIDI device. The udev event relates to the bluetooth connection, not the alsa client creation. This gives two issues:
- Don’t know the name of the alsa client
- Delay between the udev event (bluetooth connection) and alsa client being instantiated
I have worked around this temporarily by triggering a script that waits a second then routes my device but that isn’t robust nor scaleable. FYI here is the udev rule:
ACTION=="add" , SUBSYSTEM=="bluetooth", KERNELS=="hci0", RUN+="/home/pi/test.sh"
It will run when any hci device connects but you are unlikely to pair many bluetooth devices to your Zynthian.
[Edit] This may be okay for the connect script:
#!/bin/sh
sleep 1
src=`aconnect -l|grep user|awk '{ print $2 }'`
/usr/bin/aconnect $src:0 'Midi Through':'Midi Through Port-0'
It assumes the first / only userspace alsa client is the BLE client and that the MIDI port is the first port of the device. This is likely to be true in Zynthian under most conditions.
Seems you’ve taken this a lot deeper than I did, Brian, thanks!
That’s matching my experience, glad it’s replicable at least!
I know you’re aiming for a fully automated do-what-i-mean solution, and while that’s great, I think I’d be more than happy to start with that automatic routing happening with your udev script for a device name that I can write in a file somewhere. I’m not close to the machine now, but if I understand correctly, using that alternate acconnect command you mention above, it’ll stick for the session as it’s a recognised MIDI trough port? If so this script might be all I’m after - I’ll need to play around a bit more this weekend, but that’s very promising!
Hopefully it can pave the way for a seamless support for Bluetooth devices with zynthian. Let the declutter begin!
We cross-posted. See my post above that should / may give seemless BLE MIDI connection. If we prove this is robust I will look to add a method of pairing devices.
2 Likes
It will remain routed until Bluetooth connection drops. It will re-route a second after Bluetooth connection re-establishes.
1 Like
That’s as much as we can expect from a Bluetooth connection, if we needed more stability than that we’d be using a cable 
1 Like
Ok. couldn’t wait for the weekend. Added the udev rule above, wrote the test script (had to chmod +x to make it run, should anybody want to replicate). Also did an update, for good measure (got a bit scared when I saw rpi-update messages popping up on the logs, but everything went smoothly).
Turned on the foot controller, and it just works. Turned it off and on a few times, played around for ten minutes or so, and didn’t go down once. Success!
Considering the limitation you mentioned (having just the one BLE device connected at a time), I’d say having this turned on by default is better than the alternative - there’s still the nasty pairing to be done, but that’s a one time thing, harmless with the right instructions as per start of this post (ok, maybe not for everyone - but it’s a step in the right direction )
Just FIY, I never got around to play with a good looper (just a single push button guitar pedal one, which wasn’t ideal). So getting a £20 device online that extends Zynthian in such a versatile way is making me value this project even more. And yes, that’s thanks to you guys, kudos!
5 Likes
Resurecting this thread because I may be getting some BLE toys for Christmas… I have been trying to get Bluetooth (BLE) MIDI working and was failing because:
- All the online stuff seems to be wrong!
amidi -ldoes not show ALSA seq devices- Android BT MIDI does not seem to be compatible
I created a BLE MIDI device using an ESP32 and got some MIDI messages into Zynthian. This post is mostly to remind myself of the issues I have had so far.
In one of my planned projects, I would like to use the widi core module.
I have good experience with GME WIDI, so maybe it could work. Besides, I don’t want to deal with an order from HONG KONG and customs, tax, etc.
I have read a couple of articles that suggest jack MIDI support is poor with bad jitter, e.g. The Ardour Manual - MIDI on Linux, particularly the statement:
Using a2jmidid acts as a bridge between ALSA MIDI and JACK. The -X seq or -X raw arguments should not be used—the timing and performance of these options is unacceptable.
I wonder whether we should consider changing Zynthian to use a2jmidid exculsively. By using the -e argument you get all the physical ports exposed, including BLE (bluetooth) connections. The current Zynthian code does not recognise these ports but it should be simple to fix this. It would also provide per-device access for ALSA MIDI ports which is currently only done on a combined (all ALSA MIDI ports) basis - they are all or none selected.
When I previously looked at this I thought there were issues to this approach but my (rather brief) tests today suggest it may be a good path. With respect to the topic here (Bluetooth MIDI) it would remove the need for any extra routing scripts and make the ports available natively. I will do some further tests to see how much work would be required to implement this and what the impact may be on operation / behaviour.
That looks cool - much lower power requirement than the ESP32 that I am using for my current tests but a lot more expensive (x10). I like the idea of a BLE MIDI device that can be powered by MIDI DIN-5 (as the CME WIDI devices do:
3 Likes
Yes it is true. On the other hand, there is no need to develop software for BLE connection and midi communication. It is compatible with WIDI devices from CME. It is a closed system with which you only need to connect to RX and TX.
What I like about WIDI CME is that it is possible to use the application to create groups that are connected. I have tested the connection between WIDI Master, WIDI Uhost, WIDI Bud Pro, Genki Wave Ring, Artnois Re.corder at home. It was exhausting and sometimes frustrating to figure out how to put it together, but in the end it works.
1 Like