Is SQ midi controllable without a computer?

We are considering an SQ5 in the band, but I would like to select scenes using a midi controller without bringing a laptop to the venue. I understand that you can connect the SQ to a Mac using USB or ethernet, but can you also send midi events directly between a midi controller (such as a keyboard) and the SQ? Or do you need a computer between the keyboard and the mixer in order to have the SQ switch scenes when I select a preset on my keyboard?

Midi over ethernet works without computer as well
you need something to convert the messages to normal midi

Interesting. So lets say my keyboard normally delivers MIDI to my computer via USB, and my computer is able to deliver MIDI to the SQ via midi over ethernet, then what you are saying is, theoretically something else could act as the midi converter instead of my computer. But what would that something be if not a computer?
My issue is, if I can avoid it, I’d prefer not bringing an expensive laptop along just to act as a midi converter. I am actually surprised, Allen & Heath did not just include old school DIN midi sockets like all the Behringer and Midas mixers do. Most midi keyboards and guitar effect boards have them.
What would be really cool is, if I could connect the USB midi socket from my keyboard directly to the SQ, but I do not thing I can, because both are a USB-B connectors, and I have never seen a USB-B to USB-B cable. These cables are always USB-B to USB-A, and I am guessing this is because one is not supposed to connect devices that way, but I am not sure.

1 Like

https://www.bome.com

sorry was clicking to fast…

Great! Thanks Steffen.

I also found this device, does not support ethernet, but is also a bit cheaper.

A bit late to the party, but I actually used a small Microcontroller with an Ethernet port instead of the “boome” device - which I also looked at.
A bit of a learning curve, but a lot cheaper. Luckily I could load Circuitpython on the controller and didn’t need to handle all that TCP/Ethernet stuff - it’s offloaded to a chip on the board…

I’m just using it to toggle two mute groups with one footswitch to realize a talkback/“talk to band” feature from the same microphone for our Musical Director. That way I can configure a second channel strip for the same mic that doesn’t get routed to speakers and switch between both via foot switch.

I could also share the code I wrote for that…

2 Likes

(Unfortunately :slightly_smiling_face:) I don’t need anything like that (at the moment), but I think your approach is really great!
Am I right in assuming that you’re basically only using 2 IO capabilities of this tiny’s to switch your mutes (via MIDI)?

Hi @einhirn ,

I’m thinking about doing something similar with the GLD, but got stuck at the network midi protocol used.
For Windows and macOS there’s the MIDI Control app for translating network to a native virtual midi port, and so far I’ve only seen people claiming that this is done via a custom protocol by A&H, and that’s why simply using rtpMIDI won’t work. How did you solve this? Is it just AppleMIDI but on a TCP connection instead of RTP, or is it necessary to implement something completely different on the MCU?

Thanks in advance!

Benedek

Thats right - I’m using two GPIO pins for two foot switches. For now. Since this MCU has some more GPIOs, who knows :slight_smile:

1 Like

A&H uses a kind of proprietary protocol, but at least it’s dead simple, at least for SQ series. It’s just a TCP connection and midi messages sent/received across it just as they would be on a regular 5-pin MIDI-connection. I just studied the MIDI Protocol description long enough to figure out what I needed. I’ll just post the code, probably easier to read that than me explaining it. You’ll find almost no Code concerning the TCP stuff - the Ethernet/TCP-to-UART controller can be set up via a Windows program, so that’s what I did. There’s a way to do it from the program, though. I just didn’t need to do it, so I didn’t.

This is circuitpython - so if you’re afraid that working with a MCU-Board will be akin to black magic: It doesn’t have to :smiley: There’s a button on the board which you hold down while plugging the board into USB - it appears as a flash drive. Copy the appropriate circuitpython runtime onto it. Safely remove said flash drive. Plug in again, a different flash drive will appear. Place python code there, done.

An IDE like “mu” will help, as will reading some basic tutorials

import time
import board
import neopixel
import busio
import digitalio
import keypad
 
# \xB0 is for MIDI-Channel 1 - perhaps should be easier to customize?
MUTEGROUP5 = b'\xB0\x63\x04\xB0\x62\x04'
MUTEGROUP6 = b'\xB0\x63\x04\xB0\x62\x05'
MUTEGROUP7 = b'\xB0\x63\x04\xB0\x62\x06'
MUTEGROUP8 = b'\xB0\x63\x04\xB0\x62\x07'
MUTE = b'\xB0\x06\x00'
OFF = b'\xB0\x26\x00'
ON = b'\xB0\x26\x01'
 
# Init LED
pixels = neopixel.NeoPixel(board.LED, 1)
 
# Init communication to Ethernet converter
ah_tcpmidi = busio.UART(board.GP20,board.GP21,baudrate=115200)
 
# Input will be low when connected
tcpcs = digitalio.DigitalInOut(board.GP17)
tcpcs.pull = digitalio.Pull.UP
 
# Footswitch will connect GPIO pin 2 to ground
# Footswitch-Pins (add more as needed)
BTN_PINS = ( board.GP2, board.GP3, )
 
# Initialize footswitch inputs (with Pull-up-resistor)
buttons = keypad.Keys(BTN_PINS, value_when_pressed=False, pull=True)
 
# Reset Ethernet converter?
#rsti = digitalio.DigitalInOut(board.GP19)
#rsti.direction = digitalio.Direction.OUTPUT
#rsti.value = False
#time.sleep(0.5)
#rsti.value = True
 
# Some 7-Bit-Math, but should be universalized... BTW this isn't actually used in this program
def get_ip2group_val(ip, group):
    # 0x67 = 0x6674 (First input/group) - 0x6600 (because of 7-Bit math)
    ip = (ip - 1) % 48
    group = (group - 1) % 12
    val=0x74 + ip * 12 + group
    valhigh = (val >> 7 ) << 8 # keep only bits above 127 and shift up one.
    vallow = (val & 0x7f) # only bits below 128
    val=valhigh + vallow + 0x6600
    return val.to_bytes(2,"big")
 
while True:
# Read received data, if any
# FIXME - limit time spent here...
    while ah_tcpmidi.in_waiting:
        data = ah_tcpmidi.read(ah_tcpmidi.in_waiting)
        print(data.hex(':'))
        print(data)
 
# Blink red while waiting for established connection
    if tcpcs.value:
        while tcpcs.value:
            pixels.fill((0, 127, 0))
            time.sleep(0.5)
            pixels.fill((0, 0, 0))
            time.sleep(0.5)
        else:
            pixels.fill((127, 0, 0))
 
    event = buttons.events.get()
    if event:
        print(event)
        if event.pressed:
            if event.key_number==0:
                # Mutegroup 5 on, Mutegroup 6 off
                command = b''.join([MUTEGROUP5,MUTE,ON,MUTEGROUP6,MUTE,OFF])
            elif event.key_number==1:
                # Mutegroup 7 on, Mutegroup 8 off
                command = b''.join([MUTEGROUP7,MUTE,ON,MUTEGROUP8,MUTE,OFF])
            ah_tcpmidi.write(command)
            print(command.hex(':'))
            pixels.fill((127, 127, 0))
        if event.released:
            if event.key_number==0:
                # Mutegroup 5 off, Mutegroup 6 on
                command = b''.join([MUTEGROUP5,MUTE,OFF,MUTEGROUP6,MUTE,ON])
            elif event.key_number==1:
                # Mutegroup 7 off, Mutegroup 8 on
                command = b''.join([MUTEGROUP7,MUTE,OFF,MUTEGROUP8,MUTE,ON])
            ah_tcpmidi.write(command)
            print(command.hex(':'))
            pixels.fill((127, 0, 0))
 
    time.sleep(0.1)
2 Likes

Thanks! I know a fair bit about microcontrollers, but was unsure if it’s worth exploring the Ethernet midi control, or I should just go with regular old DIN midi (the GLD still has that, but it’s a bit annoying, that you need two cables for bidirectional communication). I guess I’ll go ahead and try what you did for the SQ (and thanks for the code, btw!), since I don’t see a reason why A&H would change this protocol between the different consoles.

The TCP Port they use seems familiar. But the MIDI-Messages might differ from what I used on the SQ…

Yeah, the actual messages do indeed differ, but interestingly it looks like the SQ is the one that is being an exception here.
From its document it looks like the MIDI support on it is pretty barebones, especially when compared to the Qu, on which you can basically set up an entire show using only MIDI. The messages are also unlike any other I came across when looking at the other boards’ MIDI documentation. I hope there are no such big differences in their midi network protocols though, but I’ve yet to find that out.

Thanks for your explanations, the link, and the really well documented code!
It’s all very interesting to me.