So I have spent a little bit of time starting to capture TCP commands for dLive in the hopes of supporting the companion module.
I have attached what I have collated so far.
My process is to link director to the mixrack & surface open wireshark then press a command in director which gives me the TCP data packet
I then test the packet using packetsender sending to the mixrack IP to check.
I will be updating the list as I go and upload new version of the packets.
its in googlel sheet format.
What I’d love to concentrate on is getting feedback from the MixRack. ATM the MixRack does not transmit anything back on the TCP line. Obviously it does when connected to a surface, editor or controller, so we have to figure out how to get the MixRack to send data to the module.
Here is a wireshark capture of what happens when i use packet sender to send FX 1 Mute code string. Maybe this will help? I had to zip it to attach the file type.
If this is helpful I can do one of these for each thing I record in the data sheet.
I don’t need any raw captures, I can do those myself.
What you sent in the spreadsheet is fine.
What’s most important now though is figuring out how to receive messages from the MixRack and Surface. If you can figure any of that out, that would be great!
To do the bus muting properly, we’ll need feedback from the console giving out the bus types and names. Let’s leave that function until we can establish communication back.
The Pre-ABCD message looks to be a command for every channel, so again we’ll need to be able to read the current state so we can change the single channel desired.
StuartW, what port(s) did you use and IP’s? Trying to replicate with packet sender directly to director instead of mixrack.
Hey Andy, Nathan here.
I still need to test if IP8>director is reference based or command based still.
I can’t figure out how to send the data to director, it seems to want an open socket. Packet sender always says “could not connect.” not sure if it’s filtering by IP or port or both, but I’ve tried both idential ports and packet sender on same IP so I’m thinking its binding to the mac now? Not sure how typical programs handshake.
Probably need to build a .net program to try some things out as packet sender seems lacking (specifying a specific tcp port isn’t working).
Data below is for: IP8 connected to director with or without mixrack works for ‘Sel’ and ‘Mix’ the two more useful commands to send via Companion IMO.
IP8 73 > Director 162 = Sel CH1 on Fader 1, Top button
6 1.335448 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f0000128160003100b000101f7
IP8 73 > Director 162 = Sel CH1 on Fader 1, Top button
11 2.743507 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f0000128160003100b000101f7
IP8 73 > Director 162 = Sel CH2 on Fader 2, Top button
20 4.120072 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f0000128160004100c000100f7
IP8 73 > Director 162 = Sel CH1 on Fader 1, Bottom button
8 2.354990 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f000012816000b1013000101f7
IP8 73 > Director 162 = Sel CH2 on Fader 2, Bottom button
18 3.173907 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f000012816000c1014000101f7
I still need to test if IP8>director is reference based or command based still.
I can’t figure out how to send the data to director, it seems to want an open socket. Packet sender always says “could not connect.” not sure if it’s filtering by IP or port or both, but I’ve tried both idential ports and packet sender on same IP so I’m thinking its binding to the mac now? Not sure how typical programs handshake.
Probably need to build a .net program to try some things out as packet sender seems lacking (specifying a specific tcp port isn’t working).
The Port to speak to the MixRack is 51321, TCP.
Data below is for: IP8 connected to director with or without mixrack works for ‘Sel’ and ‘Mix’ the two more useful commands to send via Companion IMO.
IP8 73 > Director 162 = Sel CH1 on Fader 1, Top button
6 1.335448 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f0000128160003100b000101f7
IP8 73 > Director 162 = Sel CH1 on Fader 1, Top button
11 2.743507 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f0000128160003100b000101f7
IP8 73 > Director 162 = Sel CH2 on Fader 2, Top button
20 4.120072 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f0000128160004100c000100f7
IP8 73 > Director 162 = Sel CH1 on Fader 1, Bottom button
8 2.354990 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f000012816000b1013000101f7
IP8 73 > Director 162 = Sel CH2 on Fader 2, Bottom button
18 3.173907 192.168.1.73 192.168.1.162 TCP 67 51321 → 58960 [PSH, ACK]
f000012816000c1014000101f7
Interesting. I’ll see what can be done with those.
Clearly the MixRack will communicate with the surface, director and other controllers.
However, it seems like there’s some handshaking that goes on, likely over UDP that tells the MixRack that it’s ok to send to that controller. The controller then most likely keeps sending a “I’m still here” heartbeat, again likely over UDP.
Okay so creating a fake IP8 IP in director tells director to look for a connection on port 51321 [this is consistent between restarts].
Once it establishes a connection they talk back and forth on that same port.
There is some sort of handshake where they exchange identities and then keep that going throughout the conversation.
I’m 50% certain UDP is only utilized for metering as per talking to the devs at Infocomm about custom control.
[listening socket]
--------------------------------
Time: 16:53:04.141
From: 192.168.1.83:50882
TO: 192.168.1.83:51321
Method: TCP
ASCII:
\f0\00\03\00\00(U\00\04\00\17IP Controller Identity\00\f7\e0\00\04\01\03\f3`\e7
HEX:
| F0 00 03 00 00 28 55 00 04 | 00 17 | 49 50 20 43 6F 6E 74 72 6F 6C 6C 65 72 20 49 64 65 6E 74 69 74 79 | 00 F7 | E0 00 04 01 03 F3 60 E7
Time: 16:52:49.081
From: 192.168.1.83:50879
TO: 192.168.1.83:51321
Method: TCP
ASCII:
\e0\00\03BYE\e7
HEX:
| start | unknown?? |stop|
| E0 00 | 03 42 59 45 | E7 |
---------------[actual handshake]---------------
From: director
From: 192.168.1.83:51219
To: IP8
To: 192.168.1.73:51321
Method: TCP
ASCII:
.p.2.......(.....IP Controller Identity..........
HEX:
| ?? | start | I P C o n t r o l l e r I d e n t i t y | stop | start | ?? ?? ?? | Director Identity |stop|
| f0 00 01 00 00 28 16 00 04 | 00 17 | 49 50 20 43 6f 6e 74 72 6f 6c 6c 65 72 20 49 64 65 6e 74 69 74 79 | 00 f7 | e0 00 | 04 01 03 | c9 d1 | e7 |
From: IP8
From: 192.168.1.73:51321
To: Director
To: 192.168.1.83:51219
Method: TCP
ASCII:
........
HEX:
| start | ?? ?? ?? | IP8 identity |stop|
| e0 00 | 04 02 03 | c0 01 | e7 |
Well, i’ve been at this for a few hours now. Not really any closer.
https://www.allen-heath.com/media/dLive-MIDI-TCP-Protocol-1.50.pdf
I have a lot of data, they seem to follow the midi protocols somewhat closely (or really vise-versa, as midi was later).
f7 is a stop code for sure straight outta midi document.
the input channel correlation is quite off for the IP8.
I’m sure the f0 stuff is SysEx header data; but modified for controllers and such (not midi)
I’m 99% sure the IP8 is a reference based system (it’s basically a midi controller), all of the ‘code’ that makes the buttons do things is in director; not the mixrack.
That makes things nice though because sending commands to director should be [relatively easy] for a reference based system.
Still unknown how to send the commands to director as a ‘fake’ IP8. Director tries to make a connection to packet sender on the same IP and packet sender can establish a socket. But sending commands doesn’t work still.
Not sure what I’m doing wrong.
----------------------------
CH1 Director > IP8
1) f0000100 22 28161000000102f7f00001003 b 281 7 100 a 000101f7f0000100 1a 2816100000010 2 f7f00001003b2817100 3 000101 f7
CH2 Director > IP8
1) f0000100 23 28161000000102f7f00001003 c 281 8 100 a 000101f7f0000100 22 2816100000010 0 f7f00001003b2817100 a 000100 f7
2) f0000100 1b 28161000000102f7f00001003 c 281 8 100 3 000101f7f0000100 1a 2816100000010 0 f7f00001003b2817100 3 000100 f7
----------------------------
CH1 Director > CDM32
no idea
CH2 Director > CDM32
no idea
----------------------------
IP8 CH1 Top > Director
f00001281600 03100b 000101f7
IP8 CH2 Top > Director
f00001281600 04100c 000101f7
IP8 CH1 Bottom > Director
f00001281600 0b1013 000101f7
IP8 CH2 Bottom > Director
f00001281600 0c1014 000101f7
----------------------------
Director > IP8 - [set] CH3 Top Button as 'Sel > input > CH3'
f00001003d2819100200080100020053656c00f7
Director > IP8 - [set] CH4 Top Button as 'Sel > input > CH4'
f00001003e281a100200080100020053656c00f7
Director > IP8 - [set] CH3 Bottom Button as 'Sel > input > CH3'
f00001003d2819100900080100020053656c00f7
Director > IP8 - [set] CH4 Bottom Button as 'Sel > input > CH4'
f00001003e281a100900080100020053656c00f7
----------------------------
IP8 CH1-4 Bottom > Director [Setup to 'Sel' input 1-4 in director]
f00001281600 0b1013 000101f7
f00001281600 0c1014 000101f7
f00001281600 0d1015 000101f7
f00001281600 0e1016 000101f7
IP8 CH5-8 Bottom > Director [Setup as nothing]
f00001281600 0f1017 000101f7
f00001281600 101018 000101f7
f00001281600 111019 000101f7
f00001281600 12101a 000101f7
----------------------------
[only works if nothing assigned to fader]
Director > IP8 - CH8 Fader
0% - f0000100382816100000020000f7
100% - f000010038281610000002fffff7
IP8 > Director - CH8 Fader
0% - f0000128160038115400020000f7
100% - f000012816003811540002fffff7
Are you thinking that mimicking the IP8 would be a better way to communicate than emulating Director?
My feeling its that, like the Custom Control, the IP8 sends the same information (e.g. Button #1 is pressed) and it’s the MixRack that assigns that function to “Mute Ch1” (e.g).
If that’s the case, then using the IP8/Custom Control method would be a lot harder (or at least require programming of the MixRack to the various Companion buttons) and wouldn’t necessarily allow for all functions.
I think I found my issue with packet sender & the command. To establish a connection to director I need a persistent connection. Packet sender doesn’t send hex (found via wireshark) when in persistent connection mode (only ascii) thus the data string in the tcp packet is always incorrect.
Converting to ascii from hex to send is a no go as ‘00’ is ‘nul’ and doesn’t work. Need to create a tcp socket hex sender server or something like that.
Remember that both the surface (director in this case) and the mixrack can create/control their own set of IP1/6/8/GPIO Devices.
But I get what you’re saying, forcing the user to create some (or many) fake IP8 controllers is time consuming and annoying when trying to deploy companion.
You want to say hit this IP address and ‘sel’ for CH1-128 should just work.
I guess I skipped over trying to send commands to director directly as it seemed impossible with no documentation.
I mean we could brute force it, try all the ports and protocols and just send ~random~ data to each one?
I guess a work around is you can hit the mixrack with a command (‘sel’) and it then will return a command to a surface/director hopefully selecting that channel; but as 4 surfaces (hardware or software) can connect to the mixrack I’m not sure how it’s handling how to display on the surfaces that a channel is selected.
Additionally, I tried wire-sharking the director > mixrack Ch-Sel data and it is super confusing. CH1 and Ch2 data is identical and there are multiple [PSH] packets. So the surface to director connection is MUCH more involved.
Stu and I have already sniffed many of the Director’s TCP commands. I think that’s the best direction to focus.
Have you tried the module? (You don’t need a StreamDeck, just a MixRack) It shows the TCP that’s output on each action in the logs.
Have you looked at what we’ve got so far? The code is here and it all works.
As I say, the big hurdle is figuring out the handshake(s) required to tell the MixRack to send data to the module, as it does for Director and the Surface. We need the MixRack to think it’s talking to one of those.
Why is send commands directly to the mixrack necessary and why do you need the mixrack to send data back to the module? Isn’t that re-creating Director?
I figured you’d want to control Director as that’s the only useful use-case I can think of??
Once I understand better I can focus on that for you.
Off topic: In the mean-time, development on the midi environment should be completed IMO, I was surprised Jefferey hadn’t done so, but I’ll go comment on the midi module for that.
Good question! My thoughts were that this would simply be an expansion from the current MIDI control (which can control both the MixRack, Director or maybe even a surface) to allow for further control and to include commands that are missing from the MIDI implementation.
I figured you’d want to control Director as that’s the only useful use-case I can think of??
Maybe you can explain why you feel that’s a function that’s needed or a “better way”?
I wouldn’t expect to be normally using a SD with Director running, I’d just use Director or Custom Control instead. Keep in mind that Companion also works with the Raspberry Pi, so a setup with a SD and RPI connected to a surface doesn’t need a (regular) computer to operate.
Once I understand better I can focus on that for you.
No, please, tell me what you envisioned, as perhaps there’s a different or better way to attack this. There’s no bad ideas!
Off topic: In the mean-time, development on the midi environment should be completed IMO, I was surprised Jefferey hadn’t done so, but I’ll go comment on the midi module for that.
Not sure if he’s going to work on that further, or whether my module will replace that one… However, I’d be happy to look at the module if he doesn’t have time…
The way I see SD being utilized with companion is as a sidecar for dLive Director + IP8 wings setup. Or giving extra buttons for a surface (C1500 is a likely candidate).
The MIDI protocol is lacking the most useful commands for a FoH live mixing setup. It is somewhat useful for the integration crowd.
The three useful commands are:
Sel (input, mix, mtx, group, DCA)
Mix (SoF mode enable for mixes or inputs)
Softkey (either additional softkeys or firing the ones available on a Director+laptop setup)
In the future I’d love to see other capabilities emulated that a surface might have access to, but that Director doesn’t have such as HPF, insert, +48v, polarity, etc. It would need to follow the currently selected channel to be useful though.
When I was helping Jefferey develop the MIDI module for companion I started down the path of sniffing the Sel, Mix, & Softkeys; but I never got very far with it.
When controlling devices (Director, Surface, IP1,6,8,GPIO, Mixrack) I see three modes.
[also don’t forget, director can be in side-car mode or standalone mode]
[Furthermore, this gets super complicated with role filters and such.]
[Keep It Simple Saint for now…]
Global affects all devices.
Hybrid affects some devices but not all.
Single affects only that device.
Global Example 1: Mute CH 1. [all surface UI change to produce that difference, mixrack mutes CH1] [Provided all surfaces have layouts with CH 1]
Hybrid - While we know that mixrack changes are global (changing CH1 EQ affects all surfaces), but don’t necessarily affect the surface/director UI (you’d only see it if you were looking at CH1 on a surface/director instance).
Hybrid Example 1: [Director/surface w/ IP8 connected to it + mixrack + 2nd surface/director] scene recall on 1st changes the director/surface & IP8 & mixrack but not other surface/director. [uitilzing scene limiting & role filters]
Hybrid Example 2: hitting ‘Mix’ on a Aux1 causes the surface to enter SoF mode. This channges sends to Aux1 at the mixrack, but hitting ‘mix’ does not make the other surfaces enter the SoF mode.
Single Example 1: Softkey on Director can be triggered to spill DCA 1. DCA1 doesn’t spill anywhere else or in mixrack, just on Director
Single Example 2: Softkey on Director triggers scene triggers layout change
Single Example 3: Softkey on Director triggers Midi command or peak hold actions.
Honestly thinking through all these scenarios gives me new appreciation for the A&H multi-surface teams. I am super impressed they didn’t make CDM run different less capable firmware too. Thanks A&H
Anyways, thinking too hard about this all as it’s really pretty simple. Send commands to a Surface/Director and let the A&H system take care of the rest.
Most commands from Companion SD will be hybrid I think. But it doesn’t matter as Mixrack & Director will discriminate to the appropriate devices properly. We only need concern ourselves with controlling a Director or Surface.
Director is most important for offline configuration & testing. Director emulates a surface nearly perfectly so I don’t see an issue with just changing the IP address and the commands still working. [Obviously we’ll test this]
Maybe you can explain why you feel that’s a function that’s needed or a “better way”?
I wouldn’t expect to be normally using a SD with Director running, I’d just use Director or Custom Control instead. Keep in mind that Companion also works with the Raspberry Pi, so a setup with a SD and RPI connected to a surface doesn’t need a (regular) computer to operate.
I guess I just don’t see any point in reinventing the wheel or making SD run in some sort of standalone control mixrack only mode.
But my perspective will be mostly live and some install stuff.
I wouldn’t expect to run SD without Director running. There must be a usecase I’m not seeing for that.
Again though, CC doesn’t give me SoF, Sel, or Softkeys. All of which are the most useful/needed capabilities IMO.
Anyways, thanks for listening; hope that helps show my ‘vision’ I’m not after ‘my vision’ though I’m after whats best for everyone. Just show me where my thinking is incorrect though
Let’s just agree on what to tackle first. My focus was on sending commands to the MixRack, specifically commands that the MIDI implementation was missing.
If everyone feels the better direction would be Director/Surface control, then let’s move in that direction instead.
It’s important, though, that everyone understand that there are 2 separate sets of commands. There are MixRack commands that affect the audio, and there are Surface/Director commands that ONLY affect that device.
e.g. A channel mute is a MixRack command. If this happens, the surfaces reflect this change through a message sent from the MixRack to the Surface.
A channel select command is a Surface command. When this happens, no other surface reflects this change and the MixRack doesn’t even care. It just changes what information the Surface displays.
Other “surface only” commands are things like:
[ul]
[li]Channel Layout[/li]nr[li]Scene storage[/li]nr[li]Sends on Fader mode[/li]nr[li]Soft Keys[/li][/ul]
There’s a few more, but think of things that do not directly affect the audio, and you’ll get the picture.
With the “surface only” commands, I’m not even sure that it even sends that information out over the network. I’m not sure that it would need to, as it’s not something that affects other devices.
So, with that in mind, can you even make “surface only” changes, like Channel Select or Soft Keys? That’s the big question.
If you’d like to see the SD work as an extension for Director or a surface, we’ll have to determine if that’s even possible.
We already know that the idea I was running with (MixRack control) is possible and workable, but if that’s not the goal, then let’s see if the Surface control is even possible. Show me a message that affects the “Surface only”.
BTW, the above “conclusions” are only my opinion from watching how the dLive system works. I may be completely off-base, so correct me if you’ve discovered that it works a different way to the way I’ve described.
I had a crack at trying to see Mixrack -> Surface and other way unsure. Im going to try put a gigabit switch between the two and then wireshark that see how I go.
I think that may hold answer to what you are wanting.
What do you need exactly?
I know there are LOTS of UDP messages that get sent around in the system. So a way to minimize information so its more direct would be helpful.
To be honest I am in no way a coder or computer expert.
I have by accident made a surface do a channel PFL… however i do not remember how I did it.
From memory it was an incorrect code from the mute function we have.
Also apologies being behind on the thread! I never got an email notifcation… I shall check those settings
