• LoopA
  • Trying out LoopA with the Virtual BLM16x16+X

  • Edited

I would like to try how the BLM protocol works together with the LoopA by using the application Virtual BLM16×16+X. How can I set this up?
Is only the BLM port possible or can I also use on of the USB midi ports? I could not find anything about this in the settings.
If only the BLM port is possible how should I wire a standard midi in/out to that special port? Or are there perhaps already compatible din 8 to 2x din 5 cables available? EDIT: I found this schematic in the meantime: https://forum.midiphy.com/d/7-loopa-blm-splitter-cable-schematic

Thanks in advance
Timo

    • Edited

    Maybe it would be possible if I could use the midi router to route USB1 in to IN4 in (and USB1 out to OUT4) but I don’t think that option is possible right now

    And… What kind of Din 8 is used? is it the 270 degree or the 262 degree variant. The datasheet of the used connector was not clear about this: https://nl.mouser.com/datasheet/2/1628/sdf_j-3510761.pdf EDIT: it is 270 degrees, found good pictures here

      @Timo LoopA does not use the Virtual BLM16×16+X protocol to communicate with MatriX. But you can use the the Virtual BLM 16×16+X software to talk with a SEQ v4+. For both SEQ v4+ and LoopA, all communications going to the MatriX are sent via the dedicated BLM port.

      Best regards,
      Peter

        Thank you Peter, but does that mean I could still try out the BLM implementation with the Virtual BLM16×16+X app if split the BLM port and connect the Virtual BLM16×16+X via a midi interface to it?

          Hi Timo,

          VirtualBLM16×16+X can only be used to remote control a SEQ v4+

          For the LoopA, you’ll need to run the MatriX software on the real hardware, it makes use of all the available hardware features: full RGB Matias LEDs, the OLED for more information, 6x slider + joystick - all of these hardware features are needed for the LoopA, i.e. to support smooth zooming and scrolling of clips.

          Best regards,
          Peter

          • Timo replied to this.

            Hawkeye
            I’ld like to make something myself that displays the current clips in a session (and what is active).
            I miss this during live performances.

            The Matrix itself is way too big for that purpose, I am already pushing it with the space I need when I play somewhere
            So I want to use this a very small (7×7 cm) led matrix for this.

            If it is not the same protocol as the VirtualBLM16×16+X then how can I figure out the protocol used by the MatriX?

              @Timo, that will unfortunately not be easy - LoopA and MatriX perform handshaking before any data flows, and all follow-up communications are packed and optimized.
              Best regards,
              Peter

                thanks, that’s a bummer!
                Is there a possibility for me to look at the midi implementation? (discreet if desired)

                  If you feel confident working with SysEx data and know a bit about C coding, encodings and bit manipulation it may be possible.

                  Could you check first if you can read SysEx packets coming out of the LoopA BLM port?

                  I think the session info (which you are interested in) is sent by LoopA in any case - if you can read some data, then i could send you a snippet of C code which transmits the session infos (used in the MatriX overview screen, showing available clips, active scenes and so on).

                  Best regards,
                  Peter

                    Awesome, I think that sounds very doable.
                    I will report back as soon as my din8-> din5 pcb and a proper cable has arrived.

                      9 days later

                      I made this little board to split blm to midi in/out (I have spares available if anybody wants) and I got to work in max/msp

                      Upon the load of a song the current data is sent out in sysex packages, this contains (among other things, that I didn’t bother to check yet):

                      • the one that starts with 2 contains set wide info, including name, occupied patternslots and mutestates (sometimes these values are packed together in one byte).
                      • The sysex package starting with 3 contains the currently active scene, active track and trackname.
                      • The (various) packages starting with 4 contain all the note and cc data of the currently selected pattern.

                      Here is that data clumsily visualised in max :

                      This data is only sent once upon loading.
                      So the big questions right now are:

                      • How do I request an update of the current state?

                      • How do I start/stop patterns, or trigger a whole scene?

                      • How do I mute?

                      • How do I select a track? (and also start/stop/record would be awesome to know how to control).


                        I think that’s about it, not really interested in editing remotely, just performing.

                        Well done! I had the impression that getting the info out of LoopA which clips are available and what is playing back was your primary requirement (see your above post) - i can help you parse the status packets that you get, but for more remote control i think you need to go through the full handshake procedure, which we cannot document.
                        Status packets should be resent, when you select a new track/clip on LoopA.

                        Best regards and have a good weekend,
                        Peter

                          Yes, my primary requirement is the parsing of the status packet and keeping that up to date.
                          However, the status update are note resend when selecting a new scene/track/clip on loopa, only on file load. Is there a sysex message I can send to force this resend?

                          Yes, my last post went further, it was so much fun that I would like to set the scene or individual tracks with button presses instead of the encoder. It would be awesome if you could share that as well. Is the reason not to share it complexity? or protection of your work?

                            Hi Timo, yes - it’s closed-source because of IP protection. The info packets should be sent on session load - my initial impression was that you just want to get “some more info” out of the unit when a scene was loaded, which i think you can do now? Any further live control and status requests are not possible without a MatriX.

                            Best regards,
                            Peter

                              I am sorry to hear that you want to keep it closed.
                              And I am sorry to hear that there is no way to keep the visualisation updated (it only can show the state it was in upon load).

                              Write a Reply...