Support for HC-05/HC-06 Bluetooth Module (Feature Request)

[ACuppaJoes]

Currently, there is built-in support for the ESP32's Bluetooth but I was hoping you could add support for the HC-05/HC-06. This way those of us who are using other boards with this common module attached can also take advantage of Midi over BLE

[tttapa]

I have no experience with these modules, but at first sight, they look like Bluetooth Classic UART modules which do not support BLE.

[ACuppaJoes]

You are correct. I am not sure how I forgot that the HC-05/06 didn't have BLE. There is an updated module called the HM-10 which is another UART device that does indeed support BLE. I am not sure if you have experience with it but support for that module would also be great.

[tttapa]

I did some quick googling but I couldn't find anything confirming that it supports MIDI over BLE. If the device allows fine-grained control over its BLE configuration, it might be possible, but it's probably cumbersome using AT commands etc.

Personally, I see no real value in adding support for this module. A basic ESP32 dev module costs about the same, is easier to configure, more flexible, has a better, and documented API, allows off-loading BLE to the second core, etc. If you can choose between adding an HM-10 or an ESP32 module to your project, pick the latter (that's what Arduino themselves do as well for their IoT boards, they use ESP32-based u-blox NINA modules).

[ACuppaJoes]

I understand your view. My main concern is with regard to using these dev boards and library for product development. Once code is written, designing a PCB with an MCU that has both Bluetooth and wifi capabilities when you only require Bluetooth, doesn't really make sense. Instead, I could use something like the HM-10 or any other dedicated Bluetooth module. In addition, the ESP32 does not have native USB support. This means I am unable to switch between midi over BLE and midi over USB. Using a Bluetooth module that connects to a midi over USB capable device such as the pro micro, allows me to do this.

At the end of the day, I'm sure most people utilizing your library are hobbyists and it's probably not worth your time integrating this kind of support.

I really appreciate you for creating a library like this and thank you for responding to me promptly. Keep up the awesome work!

[tttapa]

designing a PCB with an MCU that has both Bluetooth and wifi capabilities when you only require Bluetooth, doesn't really make sense. Instead, I could use something like the HM-10 or any other dedicated Bluetooth module.

That's of course something to keep in mind for commercial devices when you're going to produce thousands of units, but for hobby projects, it's not really a concern. The ESP32 might be overkill, but you can get one for the same price as an HM-10 module.

The HM-10 is a hobby module as well, I doubt commercial products would use it for MIDI over BLE. (I did some further googling and AFAICT, the HM-10 is intended to be used as UART over BLE only, and only supports 16-bit Service and Characteristic UUIDs, which makes using it for MIDI over BLE impossible.)

This library is just a hobby project, aimed primarily at hobbyists. Adding support for commercial applications is not really a priority.
You can always add support for other Bluetooth modules yourself, the MIDI interface API is extensible, and you can reuse the MIDI BLE parsers etc. Just inherit from the MIDI_Interface class, and implement a handful of methods for reading and writing MIDI, e.g. https://github.com/tttapa/Control-Surface/blob/3a850434fd649b2ea82855b68a9e07204bf27e95/src/MIDI_Interfaces/SerialMIDI_Interface.hpp#L18-L55

See also the BLEMIDIPacketBuilder and the BLEMIDIParser classes.
You can see how they're used here: https://github.com/tttapa/Control-Surface/blob/3a850434fd649b2ea82855b68a9e07204bf27e95/src/MIDI_Interfaces/BluetoothMIDI_Interface.cpp#L100-L116 https://github.com/tttapa/Control-Surface/blob/3a850434fd649b2ea82855b68a9e07204bf27e95/src/MIDI_Interfaces/BluetoothMIDI_Interface.cpp#L194-L195

In addition, the ESP32 does not have native USB support. This means I am unable to switch between midi over BLE and midi over USB. Using a Bluetooth module that connects to a midi over USB capable device such as the pro micro, allows me to do this.

Why not just replace the Bluetooth module with an ESP32? You don't have to use the ESP32 as your primary MCU, you can communicate with it over UART or SPI.

I've been looking into adding support for the Arduino Nano 33 BLE (which uses a nRF52840 and supports both USB and BLE), but the Arduino BLE API is lacking and there seem to be issues with the USB implementation dropping data. I've opened issues in the Arduino GitHub repos, but I didn't get any help. It's a really impressive chip, but the support by Arduino is a bit disappointing.

[ACuppaJoes]

Hey Peter, I think you are right about using the ESP32 as a standalone Bluetooth module. That seems to be the easiest solution. I did have another question.

How can I create a sysex callback and use it to display selected track names to an ssd1306 oled screen? I found the SysEx-Send-Receive example, but am struggling to figure out how I can convert hex to text and print it to oled.

Thanks

[tttapa]

How can I create a sysex callback and use it to display selected track names to an ssd1306 oled screen?

If you're using the MCU protocol, you can use the MCU::LCD class, with the MCU::LCDDisplay class to draw it to the OLED display. It's used in this example: https://tttapa.github.io/Control-Surface-doc/Doxygen/d0/d84/MCU-OLED-SSD1306-x2_8ino-example.html

I found the SysEx-Send-Receive example, but am struggling to figure out how I can convert hex to text and print it to oled.

If you're using a different protocol and you have to program it from scratch, you can find some inspiration here: https://github.com/tttapa/Control-Surface/blob/3c8ac15a258fcc45fe7822e2dd4cf40532f1db47/src/MIDI_Inputs/MCU/LCD.hpp#L72-L130

Keep in mind that the “hex” representation you're seeing doesn't really exist in the SysEx message: the SysEx data are the raw bytes sent over MIDI. Hexadecimal is just a way to present it in a human-readable format later, this is done explicitly using the AH::HexDump in the example you reference.
To display the text to a display, you don't have to convert from hex to text. The SysEx data already contains the data for the text in ASCII encoding. The display library's print functions will accept this ASCII text without issues, you just have to extract it from the message and terminate the text with a null character ('\0').

[ACuppaJoes]

I'm not sure how I missed the track names section in the example. Thank you! Is there a better place to communicate with you that doesn't require discussion in this feature request?

[tttapa]

Is there a better place to communicate with you that doesn't require discussion in this feature request?

You could open a thread in the Discussions section.