FS#56776 - [bluez] Please enable BLE MIDI support

Attached to Project: Arch Linux
Opened by Albert Gräf (aggraef) - Tuesday, 19 December 2017, 20:36 GMT
Last edited by Andreas Radke (AndyRTR) - Monday, 25 December 2017, 13:17 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

bluez has had MIDI Bluetooth "Low Energy" (BLE) support since 5.44, which was contributed by Filipe Tonello, cf. https://blog.felipetonello.com/2017/01/13/midi-over-bluetooth-low-energy-on-linux-finally-accepted/. This will benefit all Linux pro audio users and musicians using Bluetooth MIDI gear such as CME's Xkey Air, Korg's microKEY Air, Zivix' Jamstick+ or Yamaha's MD-BT01 adapter. Virtually all Bluetooth-enabled MIDI equipment employs the MIDI BLE standard these days. It was originally created by Apple if I'm not mistaken (in any case all OSX versions since Yosemite have been supporting this out of the box), but is now also part of the official MIDI standard (https://www.midi.org/specifications/item/bluetooth-le-midi).

Unfortunately, this still isn't enabled by default in bluez, so a configure option (--enable-midi) is currently needed in the PKGBUILD to enable it. I'm currently doing this manually. I've tested it with my own MIDI BLE equipment (two of Yamaha's MIDI BLE adapters, the MD-BT01 and the UD-BT01). It works for me, and I don't think it will have any adversarial effect for bluez users not utilizing this feature.

FWIW, Ubuntu is also considering it for inclusion in the upcoming 18.04 LTS (https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1713017).

Would it be possible to have the --enable-midi configure option added to the PKGBUILD? We're running Arch on all of our MIDI lab computers, so it goes without saying that this would be very convenient for us. :) But as I said I think that many other Linux pro audio users will potentially benefit from it as these devices become more commonplace.

Thanks for considering!
Albert

--
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef@gmail.com
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Monday, 25 December 2017, 13:17 GMT
Reason for closing:  Implemented
Additional comments about closing:  5.47-4
Comment by Albert Gräf (aggraef) - Tuesday, 19 December 2017, 20:45 GMT
Attached: required changes to the PKGBUILD
   bluez-enable-midi.diff (0.4 KiB)
Comment by Andreas Radke (AndyRTR) - Thursday, 21 December 2017, 20:34 GMT
This would introduce a dependency on alsa-lib linked into bluetoothd (main bluez package). I'm afraid some other people wouldn't like to be forced to have alsa added to their system. Is it worth it?
Comment by Albert Gräf (aggraef) - Thursday, 21 December 2017, 22:03 GMT
Ah yes, that's true. Maybe that's also why it isn't enabled by default. Well, I wouldn't think that many Arch systems get installed without any sound support these days, but I may be wrong.
Comment by Albert Gräf (aggraef) - Thursday, 21 December 2017, 22:11 GMT
Is it worth it? That's difficult to answer. If you want to promote Arch as a system with good multimedia support, then it's a nice capability to brag about. After all, MacOS supports it, Ubuntu will soon, too. But I have to admit that only a minority of users (the pro audio folks) will really care about MIDI BLE.
Comment by Albert Gräf (aggraef) - Friday, 22 December 2017, 05:11 GMT
Thinking about it some more, how likely is it that you run a Bluetooth stack on a Linux computer without ALSA? AFAICT, BT devices are typically (1) smartphones, (2) game controllers, (3) bluetooth speakers (as well as headsets and the like), and (4) BT-enabled music applications (including MIDI apps and devices). I can't think of much else. And these would most likely require a computer capable of producing sounds.

Also, alsa-lib isn't a huge dependency. It's some 2 MB and it doesn't pull in any mandatory dependencies of its own. So, one might rather ask, is it worth disabling some useful bluez functionality and have users who need it going through the hassle of building their own package, when the only benefit is saving the installation of a single package that would most likely be installed anyway?

So, weighing the advantages against the disadvantages, I'd go for it. But you decide. :)
Comment by Eli Schwartz (eschwartz) - Sunday, 24 December 2017, 01:01 GMT
Worth considering, is that Arch usually enables everything and the kitchen sink by default, unless compelling reasons are given to not do so. Adding a 2MB dependency that users are not forced to make use of if they do not want to (having the alsa libraries on your system doesn't force you to use them), is not a compelling argument against.

If the feature caused the package to be 2MB bigger, we would not be worrying about users being "forced" to have 2MB added to their system.

(Also if you use Gnome, ffmpeg, firefox, or chromium you're already forced to have these 2MB shared libraries.)

Loading...