# Questions about the BLM Protocol and SEQV4 MIDI implementation

**URL:** <https://forum.midibox.org/t/questions-about-the-blm-protocol-and-seqv4-midi-implementation/19972>\
**Category:** MIDIbox BLM\
**Created:** [May 6, 2017, 8:07am UTC](https://forum.midibox.org/t/questions-about-the-blm-protocol-and-seqv4-midi-implementation/19972 "2017-05-06T08:07:40Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![borfo](https://forum.midibox.org/user_avatar/forum.midibox.org/borfo/32/490_2.png) [@borfo](https://forum.midibox.org/u/borfo)\
**Post date:** [May 6, 2017, 8:07am UTC](https://forum.midibox.org/t/questions-about-the-blm-protocol-and-seqv4-midi-implementation/19972/1 "2017-05-06T08:07:40Z")

</div>

Hi all - and particularly TK since you know this stuff better than anyone:

I’m writing a headless BLM scalar implementation in Python (using Mido - [http://mido.readthedocs.io/en/latest/index.html](http://mido.readthedocs.io/en/latest/index.html)) for 1-4 Novation Launchpads.&nbsp; I wanted to write something that doesn’t require the user to run a windowing system like the Juce app does - something that would be easy to run on a headless Raspberry PI.&nbsp; I’m pretty much finished with it - I’ll post it in here when I’m done.

I have a few questions though - things that weren’t totally clear to me from the BLM protocol docs, etc.

1. Can I expect the device\_id of all MB Seq’s to be 0?
2. If not, can I send a message to the seq to request its device\_id?&nbsp; How? (my sc ript currently sends a series of pings where the device ID ranges from 0 to 127&nbsp; out all 4 discovered MB SEQ ports - when it receives a ping response, the script automatically learns the port number and device ID.&nbsp; Is there an easier way to get the ID??&nbsp; (NOTE to future BLM developers: the Seq will not respond if you send it the wrong device ID) )
3. Other than the BLM Protocol document and the CC and Remote MIDI implementation documents at trunk/apps/sequencers/midibox\_seq\_v4/doc/, are there any other SEQ V4 MIDI implementation documents anywhere?&nbsp; Or are those documents a complete list of the control-type MIDI messages that the seq will send and respond to?
4. Re: the sysex layout message: F0 00 00 7E 4E \<device-id\> 01 \<num-rows\> \<num-columns\> \<num-colours\> \<num-extra-rows\> \<num-extra-columns\> \<num-extra-buttons\> F7
5. Can you explain these a bit?&nbsp; Numrows and num columns are self explanatory - I assume they should be 16 or 8 for a launchpad BLM, depending on how many Lpads you have.
6. How many colours should I say I have?&nbsp; Two?&nbsp; What is the effect of claiming more colours than that?&nbsp; Will the BLM use more than two colours?
7. What values should I use for \<num-extra-rows\> \<num-extra-columns\> and \<num-extra-buttons\> – should these be [1, 2, 0]&nbsp; on a 2 launchpad configuration, and [2,2,0] on a 4 launchpad configuration?&nbsp; …and [1, 1, and 0] on a 1 launchpad configuration?
8. Could you explain what num-extra-buttons does, and what extra buttons are available?&nbsp; Is there any additional functionality I could enable by mapping these extra buttons to the bottom row of round launchpad buttons on a 4x4 layout?

&nbsp;

---

<div class="post-metadata">

**Author:** ![borfo](https://forum.midibox.org/user_avatar/forum.midibox.org/borfo/32/490_2.png) [@borfo](https://forum.midibox.org/u/borfo)\
**Post date:** [May 8, 2017, 3:04am UTC](https://forum.midibox.org/t/questions-about-the-blm-protocol-and-seqv4-midi-implementation/19972/2 "2017-05-08T03:04:58Z")

</div>

I got a little further in my script, and now that I’m seeing the live incoming data from the BLM, I’ve got a few more questions:

Looks like pretty much everything I’m getting from my SEQ relating to the main 16x16 grid is this type of message - updating each column one at a time:

```
BLM16x16 optimized LED pattern transfer with 90° rotated view (rows and columns swapped, LSB starts at top left edge!) +--------------------------------------------+------------------------+ | row LEDs 0..6, green colour, 8th LED off | B\<column\> 18 \<pattern\> | | row LEDs 0..6, green colour, 8th LED on | B\<column\> 19 \<pattern\> | | row LEDs 8..14, green colour, 16th LED off | B\<column\> 1A \<pattern\> | | row LEDs 8..14, green colour, 16th LED on | B\<column\> 1B \<pattern\> | +--------------------------------------------+------------------------+ | row LEDs 0..6, red colour, 9th LED off | B\<column\> 28 \<pattern\> | | row LEDs 0..6, red colour, 9th LED on | B\<column\> 29 \<pattern\> | | row LEDs 8..14, red colour, 16th LED off | B\<column\> 2A \<pattern\> | | row LEDs 8..14, red colour, 16th LED on | B\<column\> 2B \<pattern\> | +--------------------------------------------+------------------------+

```

I haven;t seen any of the row-type pattern transfer messages, or the single-access messages.&nbsp; Does the SEQ use any of the other transfer approaches for the main 16x16 area?&nbsp; Or does it always use the column transfer messages?

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

For the “extra column buttons” - the 2x1 and 2x2 launchpad BLMs have two extra columns - looking at the single access transfer:

```
 Extra column buttons | 9\<row\> \<40+column\> \<button-state\>

```

Would I be right to assume that if note = 0x40, that means the first extra column, and 0x41 would mean the second extra column?

I also noticed some MIDI messages from the BLM that follow the extra column transfer format, but which are not documented in the BLM protocol document.&nbsp; But where the first extra column messages came in as:

0xB0 0x40 \<pattern\> - 0xB0 0x42 \<pattern\> -&nbsp; 0xB0 0x48 \<pattern\> -&nbsp; 0xB0 0x4A \<pattern\>

These undocumented messages came in as:

0xB0 0x50 \<pattern\> - 0xB0 0x52 \<pattern\> -&nbsp; 0xB0 0x58 \<pattern\> -&nbsp; 0xB0 0x5A \<pattern\>

Am I right to assume that these “5” based messages are an optimized transfer protocol for the second extra column?

&nbsp;

Are more than two extra columns possible with the BLM?&nbsp; Are there transfer options for more than one extra row?

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

&nbsp;

---

<div class="post-metadata">

**Author:** ![borfo](https://forum.midibox.org/user_avatar/forum.midibox.org/borfo/32/490_2.png) [@borfo](https://forum.midibox.org/u/borfo)\
**Post date:** [May 9, 2017, 9:23pm UTC](https://forum.midibox.org/t/questions-about-the-blm-protocol-and-seqv4-midi-implementation/19972/3 "2017-05-09T21:23:32Z")

</div>

Some things I learned while writing my pyBLM script:

- SEQ won’t respond to layout or ping sysex messages unless the device\_id being sent by the client script matches the device\_id of the SEQ
- The BLM client (ie: the pyBLM script) is just a dumb translator.&nbsp; All of the real functionality is handled on the SEQ.&nbsp; The only thing the BLM client has to do is&nbsp;send layout information to the SEQ, translate MIDI messages in BLM protocol format coming from the SEQ into messages the button/LED matrix you’re using will understand to light up indicator LEDs, and translate BLM button presses into the SEQ’s BLM Protocol format.&nbsp; It’s actually pretty trivial to write a BLM client once you understand what’s happening.
- It appears that the SEQ only uses the column transfer format from the BLM Midi Protocol docs to send data to the BLM, and single-access and row transfer formats are never used.&nbsp; **TK, can you confirm this?**

&nbsp;

There is some info missing from the BLM SCALAR MIDI Protocol documentation ([http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm\_scalar%2FREADME.txt](http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2FREADME.txt))

Specifically, how to address the second extra column used by the novation launchpad scalar setup.&nbsp; This should be added to the docs:

```
Sent button events: +---------------------------------------+-----------------------------------+ | BLM16x16 Buttons | 9\<row\> \<column\> \<button-state\> | | Extra column buttons | 9\<row\> \<40+column\> \<button-state\> | | SECOND Extra column buttons | 9\<row\> \<50+column\> \<button-state\> | | Extra row buttons | 90 \<60+column\> \<button-state\> | | Additional extra buttons (e.g. Shift) | 9F \<60+function\> \<button-state\> | +---------------------------------------+-----------------------------------+ ... SECOND Extra Column optimized LED pattern transfer (prefered usage): NOTE: in distance to single LED access, we always sent over the same channel! +--------------------------------------------+-----------------+ | row LEDs 0..6, green colour, 8th LED off | B0 50 \<pattern\> | | row LEDs 0..6, green colour, 8th LED on | B0 51 \<pattern\> | | row LEDs 8..14, green colour, 16th LED off | B0 52 \<pattern\> | | row LEDs 8..14, green colour, 16th LED on | B0 53 \<pattern\> | +--------------------------------------------+-----------------+ | row LEDs 0..6, red colour, 8th LED off | B0 58 \<pattern\> | | row LEDs 0..6, red colour, 8th LED on | B0 59 \<pattern\> | | row LEDs 8..14, red colour, 16th LED off | B0 5A \<pattern\> | | row LEDs 8..14, red colour, 16th LED on | B0 5B \<pattern\> | +--------------------------------------------+-----------------+

```

&nbsp;

&nbsp;

&nbsp;

&nbsp;

&nbsp;
