OSC messages. Finding wheel info

I am working on an applicaiton to talk to EOS using OSC

I have setup a TCP connection, and enabled  OSC TX and I am seeing messages go back and forth.

I have a question re what is returned when a channel is selected, and how to know what my wheel values are.

Example.

/eos/user/11/cmd,,  41#(s)     ( IE select channel 41 as user 11)

I see some standard replies such as

/eos/out/user/11/cmd , LIVE: Cue  1 : Chan 41 # (S) 0 (I)
/eos/out/cmd , LIVE: Cue  1 : Chan 41 # (S) 0 (I)
/eos/out/active/chan , 41  [0] F-LED Test_Use_Only _4_3_L_Direct @ 773 (S)

Then I get the current wheel info for that user / channel

/eos/out/active/wheel/2 , Red  [100] (S) 3 (I) 100 (F)
/eos/out/active/wheel/3 , Amber  [100] (S) 3 (I) 100 (F)

And many more in some cases.

After the wheel info I see:

/eos/out/color/hs , 49.118282 (F) 40.685978 (F)
/eos/out/pantilt
/eos/out/xyz

Lets me know I have all the wheel info ( IE I see something other than an active/wheel message)

 if the user#  already knows what wheels/values  are in use, - the output looks something like this. 

/eos/user/13/cmd , 5# (S)
/eos/out/user/13/cmd , LIVE: Cue  1 : Chan 5 # (S) 0 (I)
/eos/out/cmd , LIVE: Cue  1 : Chan 5 # (S) 0 (I)
/eos/out/active/chan , 5  [0] C1 Generic Dimmer @ 15 (S)

And nothing else. 

The Question - How can I tell that eos has given me all of the wheel information?

The question - how do I know that there are no additional wheels for this fixture?  I could of course set a timeout but that seems inelegant.

Parents
  • i may ( repeat may ) have found an answer.  But it relies on un-documented behavior.

    If I do an /eos/ping and give a tag to the address - the tag seems to be returned in the /eos/out/ping message.

    If I do an /eos/ping immediately after the /eos/cmd the reply to the ping comes before the reply to the command

    However, if do a  command to select a channel which is not the current channel, I get back some known messages.  It seems that I could do a ping at that point and be assured that when I receive the ping the reply to the cmd request is complete.

    So the question is what is the threading model for replies.  If we start a reply sequence and get a ping, does the reply continue without interruption until complete - or does the ping get inserted into the reply stream?

Reply
  • i may ( repeat may ) have found an answer.  But it relies on un-documented behavior.

    If I do an /eos/ping and give a tag to the address - the tag seems to be returned in the /eos/out/ping message.

    If I do an /eos/ping immediately after the /eos/cmd the reply to the ping comes before the reply to the command

    However, if do a  command to select a channel which is not the current channel, I get back some known messages.  It seems that I could do a ping at that point and be assured that when I receive the ping the reply to the cmd request is complete.

    So the question is what is the threading model for replies.  If we start a reply sequence and get a ping, does the reply continue without interruption until complete - or does the ping get inserted into the reply stream?

Children
No Data
Related