Questions about the BLM Protocol and SEQV4 MIDI implementation

MIDIbox BLM
1

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) for 1-4 Novation Launchpads.  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.  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?  How? (my sc ript currently sends a series of pings where the device ID ranges from 0 to 127  out all 4 discovered MB SEQ ports - when it receives a ping response, the script automatically learns the port number and device ID.  Is there an easier way to get the ID??  (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?  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?  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?  Two?  What is the effect of claiming more colours than that?  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]  on a 2 launchpad configuration, and [2,2,0] on a 4 launchpad configuration?  …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?  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?

 

2

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.  Does the SEQ use any of the other transfer approaches for the main 16x16 area?  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.  But where the first extra column messages came in as:

0xB0 0x40 <pattern> - 0xB0 0x42 <pattern> -  0xB0 0x48 <pattern> -  0xB0 0x4A <pattern>

These undocumented messages came in as:

0xB0 0x50 <pattern> - 0xB0 0x52 <pattern> -  0xB0 0x58 <pattern> -  0xB0 0x5A <pattern>

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

 

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

_____________________________

 

3

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.  All of the real functionality is handled on the SEQ.  The only thing the BLM client has to do is 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.  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.  TK, can you confirm this?

 

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)

Specifically, how to address the second extra column used by the novation launchpad scalar setup.  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\> | +--------------------------------------------+-----------------+