Search Results for 'qu midi protocol'

Summary

After approximately 1 hour with the board, investigating settings, peripheral software, and controls. I was able to recreate the freezing of the console interface. It still passed audio but does not allow for any control on the SQ5 console, PC software, Mac software, iPad, or Stream Deck(companion server). I was about to wrap up my investigation and documentation and the console decided to lock up. It is possible that as I attached more control software the console gives up.


I attempted to disconnect the network line to the board. The issue did not resolve.

I attempted to discover the board on the control software manually, and this did not resolve.

I was forced to reset the board via the power switch on the back right side of the board. This resolved the network issue.

I did notice on the diagnostics page at 11:40 am when originally powered on until 12:30 pm when the console froze some temperature and the fan increased. Not sure if these increases are related directly to all the remote software interfacing with the console, I tested this theory but did not see a significant change while testing. I also do not know the optimal running temp, etc, or the factual threshold of known A&H hardware issues with.


SQ5 is running the latest ‘released’ Firmware: Version 1.5.6 (r4043)

Diagnostic
11:40 AM (power on)
12:30 PM (console freeze)

Core Temp
72.59c (Max: 72.72c, Min 32.24c)
76.78c (Max: 78.5c, Min: 58.94c)

Core Voltage
0.991v (Max: 1.003v, Min 0.987v)
0.988v (Max: 1.001v, Min: 0.985v)

DAC temp:
53.00c (Max: 53:00c, Min: 25.00c)
62.00c (Max: 62.00c, Min: 48.00c)

Fan speed:
Fan1: 308rpm, Fan2: 313rmp
Fan 1: 445rpm, Fan 2: 457rpm




Version 1.5.0 – Reference Guide

https://www.allen-heath.com/media/SQ_ReferenceGuide_V1_5_0.pdf

Version 1.5.6 – Release Notes

https://www.allen-heath.com/media/Release-Notes-SQ-V1.5.6.pdf



Troubleshooting / Investigating

I experienced no issues with the console freezing while using it for 45-50 minutes. Until approximately 50-60 min in.



Multiple / all software controls were connected. (maybe this is the issue, too many software control connections)

I did investigate the network traffic during service times and this is not an issue of the network hardware as suggested in the A&H community post.

I did however tweak a network setting on the board just in case. (see below DHCP to Static)

I also corrected the iPad network settings. (incorrect network)

What devices are trying to control the board? 

iPad

I initially was able to connect and control the console via perfectly
The SQ MixPad App on the iPad is updated

The iPad iOS was on 15.5 – I updated it to iOS 15.6.1

It was also found to be on the ________ network and not the necessary ________ network to control the SQ5 console. I disconnected and “forgot the ________ network so that the iPad does not get confused moving forward.


Stream Deck w/ Companion server. (I think this could be the biggest culprit. )

I tested the stream deck. ____ and team I believe did the initial configuration of the server/controls and it seems to be working. The companion software that powers the stream deck however was not fully updated.

I updated the companion software on the Audio PC from:

Version 2.1.3 (2.1.3-6b6820cd-2696) to 2.3.0

I did find someone that was experiencing MIDI error ECONNRESET & MIDI error ETIMEDOUT issues until they updated the companion software.


One theory is that this is not a 100% sanctioned or A&H-approved control device. A&H does allow for control via MiDI commands over IP, but these TCP packets deliver over the network potentially could be causing the board to lock up from time to time. The TCP I believe even if the buttons are not being used on the stream deck. The companion server will still send packets to devices communicating the state of the SQ5 control services. Therefore bogging down the processing capabilities of the SQ5. The updated companion software has some additional settings for the SQ5. One is ‘Retrieve Console Status’.


I did pull the log file from the companion server. It shows thousands of commands received or packets of information in the couple of hours that I was testing and troubleshooting. Regardless if I was using the stream deck or not. 


My suggestion is to remove companion out of the picture for a few services and see if the console stays stable.


I recommend that ____ and team read up on the control protocol to ensure the TCP, UDP, OSC, and Ember+ are all necessary for the companion software to work with the console. I am almost positive that TCP/IP is the only required socket and listen port. However, I am not sure what other control protocols they are looking to accomplish with the companion server.

https://www.allen-heath.com/media/dLive-MIDI-TCP-Protocol-1.50.pdf

https://www.allen-heath.com/media/SQ-MIDI-Protocol-Issue1.pdf






PC – the firmware is updated to Version 1.5.0

I tested the control of the PC software and it controlled the console perfectly, the immediate fader controls also reflected perfectly on the iPad and mac software.

Mac – the firmware is updated to Version 1.5.0

I tested the control of the Mac software and it controlled the console perfectly, the immediate fader controls also reflected perfectly on the iPad and mac software.



Console –

SQ5 is running the latest ‘released’ Firmware: Version 1.5.6 (r4043)

On the SQ5. The console was configured with a dynamic IP address. It was the proper IP statically assigned on the firewall, but I changed the settings on the console to be statically assigned to 10.5.0.50 and turned DHCP off. This may help with networking confusion. (turns out it didn’t matter – as the board froze later)





[msteelParticipant]

Are you explicitly sending the scene changes via the “Custom MIDI” parameter for specific scene recalls?
Or are you relying on the built in bank/patch change messages as documented in the MIDI over TCP document to send messages for every scene recall?

Our system uses multi-surface with roles, and I think (but have not verified recently) that custom MIDI messages per scene still work along side surface roles.

However, if I correctly understand the way scene changes work with multi-surface, I can see how the behavior you describe might be a natural result of the way the system is designed. Here is why that might be, based on my observations of what happens in a dLive system:

In a dLive system, each component maintains its own set of scene memories, with data that pertains to itself. Mix Rack data (like routing and processing) for scene 10 is stored in Mix Rack scene memory 10. Similarly, Surface data (like strip layout) for scene 10 is stored in Surface scene memory 10. If there are multiple surfaces, each has its own set of memories for its own data.

First consider the case where there are not surface roles (perhaps this is even a single surface system). From what I have observed, without surface roles, a recall on any surface triggers a recall on all surfaces.
Suppose someone taps “Go” on Surface 1 for Scene 10. Surface 1 needs to recall its Scene 10 data. So does the Mix Rack, and any other Surface in the system. So Surface 1 tells the Mix Rack “Go on Scene 10.” Perhaps it uses some undocumented command to do this, but could potentially use the documented MIDI bank/patch change message for this purpose. Additionally, Surface 1 probably doesn’t know or care what other surfaces are in the system – the Mix Rack probably keeps track. In this case I think it is likely that the Mix Rack just shouts a MIDI “Bank 1 patch 10” to every device that has an active connection and lets them do their thing.

But as soon as surface roles are active in a system, scene recalls on one surface can’t automatically apply to all surfaces. In this case, the Mix Rack is probably selective about what surfaces it forwards the recall message to. It is even conceivable that the Mix Rack assumes every Surface has a unique surface role and doesn’t forward scene recall messages at all.

Here’s a wild thought – what if dLive uses the MIDI channel parameter to specify surface role? Any chance that changing the SuperRack MIDI channel would get it working again?

[BartjanParticipant]

Hello Søren,

Thank you for your answer.

Well of course I’ve tried the proposed setup. And I was baffled that A&H left out such an opportunity.

Protocol was designed to encapsulate TCP/IP data, so implementation shouldn’t be difficult (correct me if I’m wrong).

The obvious solution is ofc. Add another router in the equation. But what if we could use the connection in a broader way; tunneling midi/osc/otherdata through the available bandwidth. Would be grand!

Maybe we should turn this into a feature request?

Regards Bartjan

[KeithJ A&HModerator]

@simon C –

We use hex values throughout the documentation for clarity, these might be displayed in decimal in different programs, but they all just relate to binary values under the hood.
e.g. E (HEX) = 14 (DEC) = 1110 (BIN)
More examples here – https://www.rapidtables.com/convert/number/hex-dec-bin-converter.html

Each of the parameters you can control in the SQ have a parameter ‘address’ assigned to them, these are all shown in the tables at the end of the MIDI protocol document (so you don’t have to try and work them out). They consist of two values, MSB (MB) and LSB (LB).
You can then either send an absolute value to this parameter ‘address’, or a relative value.
With mutes you have the option to send a ‘toggle’ message, so the same message just toggles the mute state.

The easiest way to get going with it is probably to take one of the example messages and then change the values so you understand which part of the message does what.
The mute on message for channel 7, with the SQ set to MIDI channel 1 is:
B0 63 00 B0 62 06 B0 06 00 B0 26 01
This can be split into 4 messages each starting with a ‘B0’ which is just saying ‘talk to MIDI channel 1’.
The 63 and 62 identify the MSB and LSB, which in this case are 00 and 06, saying ‘do something to input channel 7’.
The 06 and 26 are related to the type of message, in this case ‘do something absolute to the mute’.
And finally the 01 at the end is to say ‘turn the mute ON’.

So you could take this and change the 01 at the end to a 00 and it would turn the mute OFF. Or you could change the 00 and 06 and change it to 00 and 2C to instead control SQ input channel 45…

As far as the connection to the SQ, for any of these NRPN messages, you should use the ‘MIDI Thru’ option in the A&H MIDI Control app, then send the whole message in one go.

HOWEVER-
NRPN’s are a little tricky to work with in some applications.
This is why we created the CC Translator option in the MIDI Control app – info on setup and use here – https://www.allen-heath.com/media/AH-MIDI-Control-V2.00-Help.pdf
If you select this, you can instead use a track in Ableton to send note on/off messages to control mutes (much easier 🙂 ).
Just set to CC Translation before opening Ableton, then set the MIDI output from a channel to the ‘Inputs’ virtual MIDI port (to control SQ input channels), and finally sequence notes to control the mutes.
Input channel 1 = -C2 (I believe).

If you need further help, you can always contact us using https://support.allen-heath.com too

Cheers,
Keith.

In https://www.allen-heath.com/media/AH-dLive-for-IT-managers.pdf under “1.2 External Control” the following is stated (emphasis by me):

TCP Rendezvous port 51325 is used for accepting external / non AHNet control messages often sent by DAWs or similar
3rd party applications. These are formatted as TCP encapsulated MIDI (hex) messages. Flow rates are dependent on client
configuration, and limited by sliding window protocol from the server.

So this means the MixRack is effectively rate limiting requests send via Midi over TCP, right? For instance SysEx messages for getting fader or send levels/mute status/channel name or color and so on might not come through. From the perspective of code implementing this interface, running into this is very bad: There is no acknowledgement of successfully transferred packages or for instance a (mirrored) header that would allow to identify the source of the request. As you cannot detect when this happens, doing client side rate limiting for sending might be the best option. :-/ And, by the way, the cap seems to be extremely conservative, so this is not a theoretical problem.

I’ve basically got two questions that might help me getting around this:

* Are there any specs on how the MixRack rate limiting is working or what’s the actual quota in total/per connection? I also don’t get what’s meant with “dependent on client
configuration”.
* Is this also affecting outbound traffic, i.e. the MixRack transmitting send levels for instance?

Maybe AH can shed some on this.
Thanks in advance!

[Mfk0815Participant]

In my opinion it makes not that much sense to just pack the Mix engine and the IO of the SQ5 into a stagebox like housing, or in other words, just build a SQ variation of the QU-SB.
The most successfull rackmount digital mixer, the X32, has several benefits compared to the A&H world.
1) it can be used as Mixer and/or as Stagebox given the Main mixer the opportunity to control the preamps of the X32 Rack. even HA split is available, unfortunatly without gain tracking.
2) the connectivity with two AES50 ports allows to connect the X32 to stageboxes or other mixers simultaneously. IN the SQ world there should be two build in SLink ports. this allows the operators to build up complex systems without loosing the expansion card
3) the extra ultranet port is designed to connect the personal monitoring system of Behringer without loosing the other ports. But you can also use the AES50 port to connect the Midas DP48 personal monitoring devices. all of those connection protocolls allows to be freely daisychained, something i miss on the most Slink-enabled protocols
4) there is a big amount of control software for a lot of operating systems. Wehn the X32 rack was introduced even the tablet based apps were enhanced to control the most aspects of the mixer, the desktop/laptop application was enhanced to control everything of the mixer.
5) there are several possibilities to enhance the system with hardware controller, MIDI based or network based (the X-Touch). even the remote apps are enabled to be controlled with MCU or HUI based controllers.
6) You can use the X32 Rack even as a loudspeaker management system because it has the right filter types on the matrix busses.

All these mentioned features makes the X32 Rack a very valuable tool for sound work. Imagine what would be when A&H to take over that features for a rack mount SQ with the IO of a DX stagebox. Imho that will be a possible game changer for A&H because it would be the best argument to pack the SQ-SB into a Inear rack for several bands or at a HOW-installation….. You can extend the system with DX stageboxes AND connect the simultaneously to the FOH console (e.g an SQ6 or SQ7). The inear mix might be controlled via a remote app, or connect the ME-systems, again simultaneously to the SQ-SB. In the case the FOH mixer is broken or there is no space for the FOH mixer you can do the job on the SQ-SB.

Or use it in your studio, where you do not need that tactile control of but a lot of preamps without wasting studio space. the monitor mix is again possible via ME or tablets.
Or, or, or

So in my opinion the SQ-Sb is far away from being pointless.

[KeithJ A&HModerator]

Hi @mikey

The main DAW Control features of SQ are part of its MIDI protocol which work in conjunction with the A&H MIDI Control App.
These include the MIDI channel strips, Bank Up/Down and MMC transport control.
You can also use the Soft Controls to send program channels, note on/off and CC absolute/relative messages, though note that you’ll need to route these directly or using the ‘MIDI Thru’ option in A&H MIDI Control.
In addition, if you’re into MIDI, there are many more NRPN messages sent and received by the core.

All of these different messages are detailed in the MIDI Protocol document here – https://www.allen-heath.com/media/SQ-MIDI-Protocol-Issue2.pdf#page=7&zoom=auto,-361,573

If you have any questions or need help with specific applications, just pop us a message using https://support.allen-heath.com 🙂

Cheers!
Keith.

Proud new user of an Avantis. We bought it to primarily be used for theatrical application. We moved from an X32 and I was sold on it with the extensive show/scene control vs the X32.

HOWEVER…

I’m having a really hard time with the MIDI implementation. Specifically, with being able to control the scenes on the console via QLAB. On the old X32 setup, I was able to just fire a MIDI command from the QLAB Computer (via midi interface) into the MIDI In port on the X32 and it would advance the next scene. Doesn’t seem like there is an easy way to do this on the Avantis.

I have read through the TCP/IP Protocol guide and realize that there is technically a way to fire off individual scenes via HEX midi — which I don’t quite understand — but what I do know is this would get amazingly complex in a large show having to manipulate QLAB with a specific (hex) MIDI command for specific scenes.

I really, really need to be able to use the Avantis Cue List and have QLAB just fire down the list that I have on the console without having to tell the console which scene to go to directly. Is there a Go Button accessible remotely and/or scene controls similar to the soft key setup window available?

Anyone else using QLAB and can give some insight/tips/help on the setup you are using?!?

Thanks!

[SteffenRParticipant]

I found the documentation about the protocol “AHM TCP Protocol V1” but no sample code in any programming language.

What are you talking about? It’s just plain MIDI over TCP…

[Mfk0815Participant]

what would be really helpful to understand is where/why this ‘faderless SQ’ would be used. i.e. why would this be chosen for use over an SQ-5 or Qu-Pac/Qu-SB?

Hmm, before we can discuss a faderless, rack version of the SQ. We should talk about a better and flexible integration of mixers to a more complex system. Maybe you should start to look over the border of the A&H dish and see what other companies do with their products. Ok, maybe you think that others cannot do that job as well or even better than A&H, but there are a lot of things you can learn imho.
First of all, I am missing two build in SLink connectors. I know, there is an option card to add a second one, but that will avoid using Dante or Waves. Two build in allows you to use stageboxes and connect to another mixing console at the same time, or allow you to connect one console with two other consoles. Sample: Monitor console with DX Stageboxes <-> FOH console <-> Streaming console.
Second, add the possibility to remote control the head amps of the local sockets or the one of aconnected stage box by a second console. This eould allow us to control the head amps of the monitor console and the connected stageboxes via the FOH Console. This will allow us to use an second, unattended, SQ as Stagebox and IEM Mixer which head amps can be controlled by Operator at the FOH console.
Additionally there is a need of a full featured remote app to control every aspect of the console In online and offline mode. The best solution is that this app is available for at least Windows, Mac, Linux, iOS and Android. Support of a hardware control protocol like MCU and a better Midi implementation will allow the user to do the job even without physical access to the console.
Then it would be time to think about a surface less reckmount console either with local IO like the QU-SB or even a version with very limited IO, some inputs for playback music, a monitor and headphone out.

[KeithJ A&HModerator]

@mike@SCS – You are correct that there are some MIDI messages which are only available using MIDI over TCP/IP, including get system state.

It is possible to use MIDI over TCP/IP to communicate between the Qu and Windows (or Mac), though for a stand-alone program you will need to implement active sensing as described here – https://www.allen-heath.com/media/Qu_MIDI_Protocol_V1.9.pdf#page=2&zoom=auto,-274,185

Another option would be to make use of ‘MIDI Thru’ with A&H MIDI Control – https://www.allen-heath.com/midi-control/ – this provides a managed connection between the Qu and Windows (or Mac!) and you can then send and receive messages using the virtual MIDI ports created.

Hope this helps!
Keith.

In my program (which runs only under Windows) I can successfully control channel mutes, etc on my QU16 using USB MIDI. However, I would also like to use Sysex messages such as ‘Get System State’, but when I try to send this message I get no response back from the QU16. Looking at the MIDI Protocol Manual I note that this is listed below info about a TCP device connection. Are these Sysex messages only available via TCP MIDI? Can I use these in a Windows environment? I’ve tried without success.

Hi there,

I use the TCP MIDI protocol a lot for automation from third party devices, and often need to fade up and down different sources. This ends up being quite a clunky thing to code into the controlling device as differences in fade duration require different arrays of 16-bit preset values (per the linear taper in the MIDI protocol documentation).

What would help greatly is knowing the mathematical relationship between the decibel value and the 16-bit linear taper value. This would mean I could program my devices to calculate the target value on the run. I’ve tried to suss it out and my wife – a statistician – couldn’t even get a particularly accurate coefficient with her clever software.

Would A&H be happy to furnish us with this? It would apply more broadly than SQ of course.

Many thanks!

[DilettantParticipant]

@volunteer

You are getting more and more ridiculous now.

I can go to any hardware store and buy some USB Storage hardware and in 99,9% of the cases that will work out of the Box with Win10, Mac, Linux, any BSD flavour, my VW Car Radio, my Android tablet and almost any other thing that needs USB storage out there. The only thing i have to care of is that it is big enough and fast enough for the task.

There are some really evil broken devices out there, but chances to get one in a shop are really low, especially when leaving out the cheap thumb drives. By far most of the available USB Storage devices sold work very well with most common USB Hosts.

In Fact, best case chances that a bought USB Storage device will work with SQ Drive are around 30% even if i leave out thumb drives and devices that are too slow by specs or generally problematic according to widespread test results.

If i counted right, from 8 common available SSD Drives with 500GB and up in the List of this Forum Thread 6 are reported to have massive Problems with SQ Drive. For 1TB SSDs only 2 are reported to work sometimes at all. 80% of the List mentions devices that are even historic and no more available to buy in regular stores.

Just sort by capacity and scroll down the list and see how many red there is in the last column!. And then strike out Hard Disks (which are really ancient now for such a task) and any device that is not actually available in stores now.

That might be ok if the SQ Mixers were out of stock since 10 Years. But as long as i can buy one at almost any bigger audio hardware store that is simply inacceptable.

So it has to be clearly stated that varying device implementations can not be the main Problem here. Facts let little doubt SQ/Qu Drive is.

If other central functions in that Mixers would work as bad (for example, the Mic Inputs would not work with 80% of the available Microphones) for sure customers would slap that desks around A&H dealers’ faces all the day.

That does not happen – mainly, because the Workaround to use a Notebook for Recording works well. Most other Mixers in that price range can’t multitrack “on board” at all or have more embarassing caveats. And because massive Multitracking might be not a very important functionality for many SQ/Qu Users at all.

The real founding of the disaster is also not so difficult to identify. A&H did not use widely available known to work USB libs since they have not included any general purpose Computer in the SQ/Qu. Instead, they made their own implementation of supported USB Protocols as a self-developed FPGA Solution.

The audio part of that seems to be really good. Maybed the developers had much more experience and references on that, maybe this part is much more easy, maybe it is just older code and thus, better tested. I don’t know about the USB/MIDI part since i did not use that yet.

But the Mass Storage part is simply a disaster for now. They tried to reinvent the wheel and ended up with some cubic thing that only can roll on specially plastered ways but they even don’t know where such ways are available, how to build such a plaster or who can do that.

I could bet if they instead had integrated some small computer Hardware like a Raspi for such tasks into the Mixer, in sum that would have gone cheaper since their FPGA developers then could focus on the good working USB Audio/MIDI part and they could use already available free Software libraries for the Mass Storage part or even outsource that. It had also some more benefits not at focus here, for example supporting more audio file formats for playback.

Without that hardware, they had to create their own Mass Storage implementation on FPGA. That includes an USB-supported Filesystem (FAT32) and since BOT isn’t sufficient for Multitracking they also need UAS what has a bunch of subprotocols down to the ATA/SCSI Command set. That is a lot of complex work.

However, even that could be done well (some day). For the Moment it definitely isn’t. SQ Drive is dysfunctionally broken with most in reality available Storage devives and even according to A&H there is no way to reliably order a storage device that will definitely work at all.

A&H could at least offer or “certify” some big USB Mass Storage devices itself. I think customers even would pay a 20% additional fee for such one if they can be sure it works then.

It is revealing that they even don’t do that. Instead, they say explicitly “we implemented something but even ourself don’t know what you need to buy to get it working”. That maybe acceptable fore some Kosmos Radio Experimenting set aimed at 14 year old pupils starting their Nerd Career, it definitely is not at all for professional Audio Gear.

[SengstakeParticipant]

Hello Nicola,
thank you for your help so far. I´m also in contact with Visual Productions(CueCore2 manufacturer) to get this to work.

To clarify the solution you supposed:

I will set the Preset in AHM-64 with a spare input channel for dimmer controls. On recalling this preset the string will be sent over TCP with an NRPM message, am I right?
CueCore2 is quite open with their protocols and can understand some TCP strings aswell. Maybe I dont need the middle man “A&H MIDI Control” on a PC/Mac?
Both products have GPI/Os so there will be a solution. But a clean over the network install is desired.

Thing is with this solution that there is still no “real time fader value over TCP”, am I getting this right aswell?

Having the customer and the design process in mind rhis would mean the following???

`Set your desired scene with dimmers
recall the preset
don’t like the dimming values?
set again with new dimming values (no immediate effect)
recall the preset with new dimmer values again to see an effect
`
So no real time fader cahnges in Custom Control app, but a way to change dimming values out of the AHM-64/Custom Control app and send over TCP to CueCore2???

I will try the computer solution tomorrow when I have access to the AHM-64 again.

Thank you for your time Nicola!
Cheers
Jan