Suggestion: AMCP Command UID

[jesperstarkar]

If you send multiple commands at once, you need a way of identifying responses to match against the commands being sent. AMCP is not synchronous in its responses.

We need to maintain backwards compatibility in adding a new optional parameter to each command. We could either add new UID to the end of each command, given that the format of this UID is distinguishable and can not be mistaken for another payload parameter at all. Or, we could optionally add a prefix value before each command, i.e:

REQ sdfkjxcvxcv PLAY 1-10
RES sdfkjxcvxcv 202 PLAY OK

[HellGore]

It is building now.

[jesperstarkar]

W.O.W !! This is the greatest news in a while! Thank you so much!

[jesperstarkar]

It works so well. Cool!

[super-ienien]

Yeah ! So cool !

[PeterAkakpo]

Current implementation of the REQ command only focuses on just the instant response from the server. I think there should be a corresponding RES command that can be use to later query a layer for the UID.
REQ 12 PLAY 1-2 AMB ----> RES 12 202 PLAY OK
RES 1-2 ------> 12
this will further help client applications to easily set the current playing item after a shutdown.

[jesperstarkar]

Hi @PeterAkakpo.

If I understand you correctly you want to be able to read out state from the server. I don't think your approach to calculate state by evaluating command responses will work for a couple of reasons:

• Multiple commands affect the current state of a given layer. A PLAY and a MIXER combined will not reflect in your approach.
• A positive command response doesn't mean the state has mutated. You can have 202 PLAY OK back without the video playing.

What you want to do is currently best done over OSC, and it seems like INFO will be added back to 2.2/2.3, and that's also a nice and simple approach.