I saw this on eBay for £25 and instantly thought it might be worth a punt…
Should have probably looked up how to Bluetooth with a zynthian first.
Running ‘bluetooothctl’ on the command line seems to do diddly squat.
Reckon I can use this as a remote anyway?
There are two steps with BT midi. First, connect the BT to the device using the standard procedure like:
https://www.raspberrypi.org/forums/viewtopic.php?t=214373
Make sure you trust it. Then you will have created a MIDI device that will re-connect. From there you need to connect the stream to zynth, but you need to do it via the OS MIDI thru port like this:
root@zynthian:~# aconnect -l
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
Connecting To: 128:0
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
Connecting To: 128:0[real:0]
Connected From: 128:0
client 16: 'f_midi' [type=kernel,card=0]
0 'f_midi '
client 129: 'UD-BT01' [type=user,pid=695]
0 'UD-BT01 Bluetooth'
Then you need to connect the device (the UDBT01 in this example) to the MIDI through port:
root@zynthian:~# aconnect 129 14
and you get this:
root@zynthian:~# aconnect -l
client 0: 'System' [type=kernel]
0 'Timer '
1 'Announce '
Connecting To: 128:0
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
Connecting To: 128:0[real:0]
Connected From: 128:0, 129:0
client 16: 'f_midi' [type=kernel,card=0]
0 'f_midi '
client 129: 'UD-BT01' [type=user,pid=695]
0 'UD-BT01 Bluetooth'
Connecting To: 14:0
That should work. Unfortunately, it doesn’t re-connect the MIDI port on re-boot.
Of course, you could probably just connect the USB cable…
Gonzo
systemctl enable --now bluetooth
This is what mine looks like
root@zynthian:~# systemctl status bluetooth
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/bluetooth.service.d
└─01-disable-sap-plugin.conf
Active: active (running) since Mon 2022-03-21 04:50:23 GMT; 1 months 4 days ago
Docs: man:bluetoothd(8)
Main PID: 626 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 2061)
Memory: 2.1M
CGroup: /system.slice/bluetooth.service
└─626 /usr/lib/bluetooth/bluetoothd --compat --experimental --noplugin=sap
Mar 21 04:50:22 zynthian systemd[1]: Starting Bluetooth service...
Mar 21 04:50:23 zynthian bluetoothd[626]: Bluetooth daemon 5.50
Mar 21 04:50:23 zynthian systemd[1]: Started Bluetooth service.
Mar 21 04:50:23 zynthian bluetoothd[626]: Starting SDP server
Mar 21 04:50:23 zynthian bluetoothd[626]: Excluding (cli) sap
Mar 21 04:50:23 zynthian bluetoothd[626]: Bluetooth management interface 1.14 initialized
Mar 21 04:50:23 zynthian bluetoothd[626]: Failed to set privacy: Rejected (0x0b)
what if you do dmesg | grep -i blue
dmesg | grep -i blue returns nothing
This was a power issue. I guess the Bluetooth shuts down if there isn’t enough juice?
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!
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:
@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:
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!