How to use?

[starfishmod]

First off thanks for the work you are doing here :)

I am a little confused on to make this work (currently working on command line only - and still very new to this)

I compiled/install your version of bluez and I have connected to a BLE peripheral via gatttool and can see data from the peripheral being sent. However I'm lost on this next stage on how this becomes a midi device in alsa? I'm sure I'm missing something fundamental but I would appreciate your help

Thanks Andrew

[ftonello]

Hi Andrew,

It's easy to use this feature of BlueZ. Make sure you are using the latest BlueZ master branch since this initial version was merged upstream already. Run the ./configure script with --enable-midi option. Then run bluetoothd normally (make sure no other instance is running). Use normal procedure to connect to a BT device to connect to your MIDI device. if you use the command line, use bluetoothctl. Once that is done, a new ALSA Sequencer client and port will be created so you can start using. To test it out, use aseqdump tool.

More info at my blog

Let me know how it goes.

Felipe

[starfishmod]

Thanks - sorry for not getting back sooner - been trying to fix other issues... I still can't get it to work but I think it is the equipment I have.

[ftonello]

Hmm, ok. What exactly is not working?

[starfishmod]

@ftonello I have a raspberry pi 3 and I'm using the Android app "BleMidiSample (peripheral)" It seems that because (from my limited understanding) it's Android it cycles it's mac address so I can connect but it doesn't register the midi device in alsa (checking this via aconnect -l)

like I said It could be something at my end though - or I could be doing something wrong I'm sure but I ran out of time to check... I might retry tonight.

[starfishmod]

So I re-investigated.. I used the bluetooth widget to "Add device" and I could connect although it was saying sending a pairing request which eventually timed out.. I then checked aconnect and got 4 connections Client 128: Oppo f1f [type=user] 0: Oppo F1f bluetooth

This repeated another 3 times upto ' Client 131' Using aseqdump and then tried to see data coming from the app. Only the last midi client (131) actually presented data. Is there a reason it creates 4 midi in's not just one?

So I also then disconnected and I noticed that it then doesn't clean up the connections. acconnect -l still will list the midi ports even when they are long gone?

I hope all this information helps

Thanks again Andrew

[starfishmod]

This repeated another 3 times upto ' Client 131'

Sorry just realised this might have been my other connection attempts that i did not think were successful...

So it's just the cleanup when a connection is stale... or reuse the old connection if it is the same device?

[ftonello]

Make sure you don't have 4 MIDI services in the same device. BlueZ only supports one MIDI service per device, which is what is recommended anyway.

bluetoothd will create an ALSA Sequencer client for each device connected and delete the client when the connection is lost.

[starfishmod]

Yep I only have one midi service in the one device. It seems that the ALSA sequencer clients are not being cleaned up on disconnect. So after I shut down the app on the phone and turned of bluetooth on the phone and then waited for a bit - the alsa sequencer clients were still there.

I'm sorry if I was a bit confusing about this earlier I was getting a bit tired :)

[ftonello]

Have you tried the latest code (from midi branch or bluez's master)? The code was updated since you opened this issue.

[starfishmod]

I'm pretty sure I did? However I will get a clean copy tonight and rebuild, I'll let you know how I go, thanks!

[starfishmod]

Just got a chance to rebuild and retest before I start work. It is still not clearing up the alsa sequencer after a disconnect. i.e aconnect - l still displays the device.

[ftonello]

Ok. So, can you provide more information?

• What steps are you taking?
• Once you connect, can you read/write MIDI data to the remote device?
• Can you run bluetoothd -n -d and check the output it provides once you start the disconnect procedure?
• If nothing shows up, please provide a btmon log as well.

[starfishmod]

Okay so I did a video here https://youtu.be/oHkkQSsBiAQ of the process for me to connect and disconnect where it did not clean up. I have also added the 2 log files you requested

bluetooth.txt btmon.txt

Hope all this helps - thanks :)

[ftonello]

Thanks for the video.

The current log you gave me doesn't help. I need more information.

Try this: kill all instances of bluetoothd running in the system. Then run bluetoothd -n -d > bluetoothd.log 2>&1 in a terminal. Do this process again and upload the log.

btmon showed that the device got disconnected indeed. So I need to see what's going on bluetoothd.

[starfishmod]

I have tried to get what you need several times, however as soon as I kill bluetoothd and restart it, I can no longer scan for devices... I'm assuming I need to restart something else afterwards? Nothing I seem to do works. In fact doing "service bluetooth restart" kills the bluetooth :/ and I have to restart the whole device to get it working again. I tried adding the --debug to the init script to no avail. I'l keep trying but not sure what I'm doing wrong here.

[starfishmod]

@ftonello attached is a log using the method requested... although not sure it it helps as when I start advertising the BLE midi app on the phone it will connect and the disconnected repeated with the phone showing it has a connection and then dropping it instantly... bltd.txt

[ftonello]

Ok, I see it has really unstable connection. But before it used to work, right?

Can you read this blog post and try my suggestion there with the configuration file?

[starfishmod]

Ok so I followed the instructions in the blog I still get it connecting and disconnecting ... just not as rapidly. Yes it worked before perfectly, it just didn't handle the disconnect. Although when I killed the bluetoothd it removed the midi device.

Since I'm obviously having trouble debugging this, are you able to please try the BLEMidiSample(peripheral) app on android and prove it's just me being troublesome :)

Also I'm wondering if it is possible that upon re-connection it looks for an existing matching connection and just reuses that? That way if it drops and then reconnects it doesn't end upon a different midi port (i.e. previously 128:0 is now on 129:0) or perhaps keep a DB of connections and ports so it handles the same ports between rebooting? Especially if there are multiple Midi BLE devices connected.

Thanks for being patient with me.

[ftonello]

Ok so I followed the instructions in the blog I still get it connecting and disconnecting ... just not as rapidly. Yes it worked before perfectly, it just didn't handle the disconnect. Although when I killed the bluetoothd it removed the midi device.

Well, based on your log, it shows that the MIDI profile is been called properly. It could be that there is as bug in the .disconnect callback. Perhaps you could check that?

About the connection reliability, it's hard to say. Are you sure you followed the steps appropriately from my blog post? For example, restarting bluetoothd after changing the info file?

Since I'm obviously having trouble debugging this, are you able to please try the BLEMidiSample(peripheral) app on android and prove it's just me being troublesome :)

I will give it a try.

Also I'm wondering if it is possible that upon re-connection it looks for an existing matching connection and just reuses that? That way if it drops and then reconnects it doesn't end upon a different midi port (i.e. previously 128:0 is now on 129:0) or perhaps keep a DB of connections and ports so it handles the same ports between rebooting? Especially if there are multiple Midi BLE devices connected.

This won't happen because the enumeration happens in the Kernel.

[patricksebastien]

Hi there, thanks for working on this (and also Roli). I have a Seaboard Rise, a USB Bluetooth 4.0 BLE and Ubuntu 16.04. My first question, do I really need to compile BlueZ (Kernel 4.4.0-77-lowlatency)? If yes, this is the right GIT repo: https://git.kernel.org/pub/scm/bluetooth/bluez.git?

[ftonello]

@patricksebastien Hi there. You need bluetoothd from BlueZ 5.44 or greater. There is no need for a special kernel build, so your Ubuntu's kernel is fine. Yes, that is the correct repository. There are more information in my blog post. Any questions just let me know.

[patricksebastien]

@ftonello Hi! It works, but not really stable: open & close many times. Is it because I am using a bluetooth USB adapter? Off topic (sorry), is it possible to use the Seaboard Rise USB on linux?

[ftonello]

@patricksebastien Yes, this is something I am working on the kernel level to improve the automatic connection parameters detection. To fix this, I have posted a work-around on the same blog post. It will fix the problem until the kernel work is complete.

Off topic (sorry), is it possible to use the Seaboard Rise USB on linux?

Yes, it does. :)

[goran-mahovlic]

Hi, I have tried to get nRF51 midi sample recognised by raspberry pi, but cannot get it to work. I have compiled bluez-5.45 with --enable-midi and used https://developer.mbed.org/users/popcornell/code/MIDI-to-BLE-MIDI-bridge/ for nRF. I have tested one app on android (https://github.com/kshoji/BLE-MIDI-for-Android) that is recognise nRF and I can connect to it.. So if someone could point me to right direction...

[brunomolteni]

hey @ftonello im trying to make this work with my Seaboard Block, but what happens is that whenever I connect to it immediatly after the devices turns off, do you know what I could do to try and fix it?

I cloned the bluez repo from the development version and compiled it with --enable-midi, and I also did the setup for minInterval and maxInterval like you said in your blog post but looks like some kind of authentication error, here's the commands I run in bluetoothctl and the log from bluetoothd

I would really appreciate any help or ideas in things I could try to make this work

[Solapse]

hey @ftonello im trying to make this work with my Seaboard Block, but what happens is that whenever I connect to it immediatly after the devices turns off, do you know what I could do to try and fix it?

I cloned the bluez repo from the development version and compiled it with --enable-midi, and I also did the setup for minInterval and maxInterval like you said in your blog post but looks like some kind of authentication error, here's the commands I run in bluetoothctl and the log from bluetoothd

I would really appreciate any help or ideas in things I could try to make this work

I have the same issue. Using Seaboard Block also

[okyeron]

Sorry to revisit this old issue, but I'm hoping for a little assistance. I'm trying to see if I can connect my ipad (as a bluetooth midi device) to a RasPi.

I have BlueZ Version 5.48 installed on RaspberryPi. So far I can pair and connect no problem. However, I believe I need some way to advertise BT MIDI to the ipad?

The iOS app I'm using (MIDI Wrench) has a tab for Bluetooth MIDI devices and searches when I open that. I can use this to connect to my Mac, but on the Mac I have to hit this "advertise" button.

Is there an equivalent way to advertise from the Raspi with bluetoothctl? I've been searching for an hour or more and can't seem to find any examples of using the advertise functions (specifically how to set a "type").

Also - it seems your blog posts are no longer available. :(

Thanks for any assistance.

[scazan]

hey @ftonello im trying to make this work with my Seaboard Block, but what happens is that whenever I connect to it immediatly after the devices turns off, do you know what I could do to try and fix it? I cloned the bluez repo from the development version and compiled it with --enable-midi, and I also did the setup for minInterval and maxInterval like you said in your blog post but looks like some kind of authentication error, here's the commands I run in bluetoothctl and the log from bluetoothd I would really appreciate any help or ideas in things I could try to make this work

I have the same issue. Using Seaboard Block also

If it helps anyone who lands here... I'm using Ubuntu 19.04 (Ubuntu Studio) and just installed the latest bluez following this guide: https://tttapa.github.io/Pages/Ubuntu/Software-Installation/BlueZ.html

Worked well to install but connecting a BLE MIDI device through the Gnome bluetooth panel was not so straightforward.

I had to open up a terminal and run bluetoothctl. Then in there, I had to trust the device before I was able to pair it. I also "unblocked" the device at some point but don't think that did anything in particular as I don't think it was blocked.

In the last working attempt, I had to turn the device off and then put it back into pairing mode, trust the device, then "connect" to it. That made it work. Now it shows up in Gnome bluetooth panel just fine and can be turned on and off from there.

I've got a Seaboard Block and an ortho remote both paired up and working with bluetooth MIDI.

[Solapse]

hey @ftonello im trying to make this work with my Seaboard Block, but what happens is that whenever I connect to it immediatly after the devices turns off, do you know what I could do to try and fix it? I cloned the bluez repo from the development version and compiled it with --enable-midi, and I also did the setup for minInterval and maxInterval like you said in your blog post but looks like some kind of authentication error, here's the commands I run in bluetoothctl and the log from bluetoothd I would really appreciate any help or ideas in things I could try to make this work

I have the same issue. Using Seaboard Block also

If it helps anyone who lands here... I'm using Ubuntu 19.04 (Ubuntu Studio) and just installed the latest bluez following this guide: https://tttapa.github.io/Pages/Ubuntu/Software-Installation/BlueZ.html

Worked well to install but connecting a BLE MIDI device through the Gnome bluetooth panel was not so straightforward.

I had to open up a terminal and run bluetoothctl. Then in there, I had to trust the device before I was able to pair it. I also "unblocked" the device at some point but don't think that did anything in particular as I don't think it was blocked.

In the last working attempt, I had to turn the device off and then put it back into pairing mode, trust the device, then "connect" to it. That made it work. Now it shows up in Gnome bluetooth panel just fine and can be turned on and off from there.

I've got a Seaboard Block and an ortho remote both paired up and working with bluetooth MIDI.

Thanks - gives me hope. Will give it another go in the next few weeks. Pretty sure I tried most of those things too - perhaps newer versions of BlueZ is the key.

[chmanie]

I'm sorry to hijack this here as well, but I don't know where else to look for an answer. I have a device running Arduino-BLE-MIDI. I can discover and connect that device as a MIDI-Bluetooth device on other computers (but not through the standard bluetooth settings). I am not able to find it using bluetoothctl. Do MIDI-Bluetooth devices have a special advertising method that is not recognized? How could I add such a device using bluez? Is that even possible? The bluez was compiled with midi as it advertises itself to other computers as a MIDI-Bluetooth device. Thanks a lot, and sorry again for posting here.

Update: I can actually see the device when using hcitool lescan. I'd really like to use the possibility to add an alsa port automatically. I really can't figure out why bluetoothctl doesn't see it.

Another update: I found that one has to filter for BLE devices: https://stackoverflow.com/a/52012231/1525722