Post by gurbz on Feb 21, 2019 9:10:09 GMT
Hi, I have a question.
i connect a Yamaha UB bt 01 Bluetooth usb-midi host to a Roland/boss katana amp.
It allows me to send sysex data with midi designer pro and the amp responds well till now.
I cannot read data from the amp, it is not usb class compliant and no driver is installed here.
on the web I found this article: gonzos.net/projects/ble-midi-adapter-ud-
This iis interesting:
To send to and receive data from the UD-BT01, you need information about the Bluetooth “handles”. A GATT scan will show that the handle for the MIDI data is decimal 26. What it won’t show you is that data needs to be sent to handle 27, and the handle for enabling notifications is 28. I don’t know if these are “standards” for BLE (sending is at data+1 and notifications is at data+2), but that’s what I found. To enable notifications, after connecting you need to send 0x01 0x00 to handle 27. When that is done the peripheral (server) will send a notification to the computer (client) each time new data arrives, and the computer then asks the peripheral for the data. BluePy/Bluez does this automatically for you.
During the connection negotiation process, the peripheral sends the computer “Peripheral Preferred Connection Parameters”. These are suggestions, and the computer can ignore them. In practice I discovered that the RPi produced high latency with the default set of parameters. I was unable to discover what those parameters were, but when I re-configured the connection using the Linux hcitool I got a good result. The command I used was:
sudo hcitool lecup – -handle $HANDLE – -min 6 – -max 6 – -latency 0 – -timeout 500
Where $HANDLE is the number of the computer’s connection handle (NOT the UD-BT01’s connection handle – they are different), – -min is the minimum connection interval (6 x 1.25msec = 7.5msec, the minimum for BLE), – -max is the maximum connection interval, – -latency is the number of intervals the peripheral can delay replying to the computer’s message, and – -timeout is the time that must elapse before a dead connection is re-established by the computer (500 x 10msec = 5sec). The min/max/latency settings I have used here give the minimum latency.
To get the computer’s handle number, use:
sudo hcitool con
The UD-BT01 appears to have a 20-byte maximum message length. I don’t know if this is configurable during the “negotiation” process, but that’s what mine defaulted to. The Apple spec implies it can be changed. MIDI commands are 3 bytes long, and with the additional header and timestamp bytes (see the Apple spec), it means that a maximum of 4 MIDI commands can be sent per message. Your program will have to determine how many commands are contained in each message (it varies). In addition, Sysex commands can be sent. These can be long, and may be broken up into multiple messages, so as not to exceed the 20-char limit. See the Apple spec for details. Your program will have to determine if each message is a Sysex (third character is 0xF0).
Header and timestamp bytes are added to the messages. For my particular application (live performance) they are not important, however, when sending header and timing bytes TO the UD-BT01, they need to meet the specification. The header byte actually contains part of the timing information (see the Apple spec), but has a minimum value of 0x80 (with a timestamp of zero), likewise the timing byte has a minimum value of 0x80. Successive timing bytes need to be increasing, so for the Sysex commands I have used the following sequence: 0x80 0x81 0x82 0x83 … This series need to be consistent only within each “batch” of Sysex commands. You can start from 0x080 again for the next “batch”.
Question and maybe very naive: is it possible to get notifications/ midi data from the amp when adding specific sysex data with streambyter?
i connect a Yamaha UB bt 01 Bluetooth usb-midi host to a Roland/boss katana amp.
It allows me to send sysex data with midi designer pro and the amp responds well till now.
I cannot read data from the amp, it is not usb class compliant and no driver is installed here.
on the web I found this article: gonzos.net/projects/ble-midi-adapter-ud-
This iis interesting:
To send to and receive data from the UD-BT01, you need information about the Bluetooth “handles”. A GATT scan will show that the handle for the MIDI data is decimal 26. What it won’t show you is that data needs to be sent to handle 27, and the handle for enabling notifications is 28. I don’t know if these are “standards” for BLE (sending is at data+1 and notifications is at data+2), but that’s what I found. To enable notifications, after connecting you need to send 0x01 0x00 to handle 27. When that is done the peripheral (server) will send a notification to the computer (client) each time new data arrives, and the computer then asks the peripheral for the data. BluePy/Bluez does this automatically for you.
During the connection negotiation process, the peripheral sends the computer “Peripheral Preferred Connection Parameters”. These are suggestions, and the computer can ignore them. In practice I discovered that the RPi produced high latency with the default set of parameters. I was unable to discover what those parameters were, but when I re-configured the connection using the Linux hcitool I got a good result. The command I used was:
sudo hcitool lecup – -handle $HANDLE – -min 6 – -max 6 – -latency 0 – -timeout 500
Where $HANDLE is the number of the computer’s connection handle (NOT the UD-BT01’s connection handle – they are different), – -min is the minimum connection interval (6 x 1.25msec = 7.5msec, the minimum for BLE), – -max is the maximum connection interval, – -latency is the number of intervals the peripheral can delay replying to the computer’s message, and – -timeout is the time that must elapse before a dead connection is re-established by the computer (500 x 10msec = 5sec). The min/max/latency settings I have used here give the minimum latency.
To get the computer’s handle number, use:
sudo hcitool con
The UD-BT01 appears to have a 20-byte maximum message length. I don’t know if this is configurable during the “negotiation” process, but that’s what mine defaulted to. The Apple spec implies it can be changed. MIDI commands are 3 bytes long, and with the additional header and timestamp bytes (see the Apple spec), it means that a maximum of 4 MIDI commands can be sent per message. Your program will have to determine how many commands are contained in each message (it varies). In addition, Sysex commands can be sent. These can be long, and may be broken up into multiple messages, so as not to exceed the 20-char limit. See the Apple spec for details. Your program will have to determine if each message is a Sysex (third character is 0xF0).
Header and timestamp bytes are added to the messages. For my particular application (live performance) they are not important, however, when sending header and timing bytes TO the UD-BT01, they need to meet the specification. The header byte actually contains part of the timing information (see the Apple spec), but has a minimum value of 0x80 (with a timestamp of zero), likewise the timing byte has a minimum value of 0x80. Successive timing bytes need to be increasing, so for the Sysex commands I have used the following sequence: 0x80 0x81 0x82 0x83 … This series need to be consistent only within each “batch” of Sysex commands. You can start from 0x080 again for the next “batch”.
Question and maybe very naive: is it possible to get notifications/ midi data from the amp when adding specific sysex data with streambyter?