• State Suggested Answer
  • +2 person also asked this people also asked this
  • Date
    mikewoodld
  • Date
  • Replies 13 replies
  • Answers 2 answers
  • Subscribers 92 subscribers
  • Views 12208 views
  • Users 0 members are here

Some OSC commands work, some don't.

So about a year ago I started working on adding integration between my FileMaker paperwork system and EOS. I ended up using simple UDP strings do to most everything, as I was having problems getting OSC to play friendly.

 

I decided to look into OSC again tonight and I'm having weird problems that I can't solve despite hours of experimentation, reading, and searching the forums and show control guide.

 

Problem 1)

I can send /eos/key/xyz/ commands and they post to the command line properly. While they do post properly, I see in diagnostics "error, OSCKeyMethod missing key name" and my searches for this error and what it means have come up blank.

 

Problem 2)

I cannot send any kind of /set/ strings or /cmd/ strings. Here's a few examples and what they show up as in diagnostics:

String Behavior Diagnostics 
/eos/set/cue/1/1/label="TextHere"
 Clears existing label String appears with everything but TextHere 
/eos/set/patch/1/label="TextHere"
 Nothing Event does not appear 
/eos/cmd="1 at 75 #"
 Nothing Event does not appear 
/eos/cmd/1/at/75/
  Nothing  Event does not appear

 

Same results for /newcmd/. I'm experiencing these issues using both my TCP/UDP sender plugin for FileMaker (MBS), as well as with PacketSender. 

What could be causing some to work but not others?

 

This all came about tonight because I'm looking for a way to send address data to patch. I can send everything else over no problem but I couldn't figure out how to get address data over and that led me down this rabbit hole. Currently to patch something the only way I can get it to work is to do:

/eos/key/open_dmx_patch/
/eos/key/1/
/eos/key/at/
/eos/key/1/
/eos/key/#/

But there has to be a better way... /eos/key/open_dmx_patch/ and then /eos/cmd/1/at/1/#/ should work, no? Is there an old fashioned UDP string that can send address data over? I tried <U1>Edit_Target address Patch 1 -1 -1 1 with no luck. 

Parents
  • 0
    i think one of the problems is how OSC transports arguments. just because the documentation says label="text", doen't mean, that it's transmitted like this. depending on how the sender handles arguments the "text" needs to go into another field or is noted after commas.

    i don't know if /eos/cmd/do/something/# is supposed to work. # is enter in an argument, but i don't know if it should work inline. i always use /eos/cmd/do/something/enter
  • 0 in reply to ueliriegg

    # works for me as enter when it's used with /key/, but not when I use /set/ or /cmd/.

    Watching the traffic in Wireshark shows me that my messages seem to be arriving intact, Eos just doesn't see whatever I put in as the label. 

    I tried::

    /label="text"
    /label/text/
    /label/text/enter
    /label=text

    and nothing. All the packets show up in Wireshark as typed but when they get to the EOS, some show up and some don't. The ones that show up have everything except the label text and typically will remove whatever label is already on the cue.

     

    As for /cmd/

    Nothing at all shows up in diagnostics, but Wireshark sees the packet as typed. 

  • 0 in reply to mikewoodld
    i claim that removing the current label is a symptom of the whole thing. it realized you want to set a label and doesn't find your argument, so it assumes you don't want to set a label.
    what happens when you send /label,text or label,"text" ?
  • 0 in reply to ueliriegg
    Same thing. Wireshark sees both of those as-entered but EOS doesn't see them at all.
  • +1 in reply to mikewoodld

    For the benefit of readers I'll post an answer here. Let me know though Mike if I didn't manage to cover everything directly.

    I shall firstly refer you all to community.etcconnect.com/.../what-is-osc
    There is a large confusion on what an OSC Message is and comparisons to a UDP String. Hopefully from reading the blog post you will understand that an OSC message is similar to a UDP String with the option of containing multiple arguments (Data Types). The general school of thought is that the address pattern, the part that is most like a UDP string is used as a description of what is being sent and the arguments are the actual pieces of data. e.g

    /eos/set/cue/1/1/label - Set the Label for Cue 1/1
    Argument - "Houselights Out"

    /eos/key/<name> - Allows you to change the "<name>" to the name of any key on the console. You can also pass a Double argument with this, either 1.0 or 0.0 to specify whether it is key down or key up. e.g
    /eos/key/Shift - press the key "Shift"
    argument - 1.0 = Press it Down

    This is really useful if you want to implement some Shift press and hold functionality into your applications.


    To address /eos/set/cue/1/1/label=" TextHere" and the problems similar. You are trying to send "/eos/set/cue/1/1/label="TextHere" as an address pattern. This isn't actually a valid address pattern for Eos and as we discussed above we want to separate the "Text Here" into an argument. The confusion here is that the format here is how you can send an address pattern and an argument from Eos via a macro or executed from cue. Essentially Eos parses that string and says, everything before the "=" is the address pattern, everything after I will figure out what kind of Data Type it is and send it as an argument of that data type.

    On top of all this we found that messages weren't at all being sent as an OSC Message but as a straight UDP String.

  • 0 in reply to mikewoodld
    The descriptions we give in the Show Control guides are aimed at people using existing OSC applications like TouchOSC, MAX, QLab etc.

    We don't attempt to describe the underlying OSC protocol as that is defined by the OSC specification.

    The packets you've shown in Wireshark are not encoded as OSC, so definitely cannot work!
    - I guess that you're trying to assemble the raw OSC UDP packets in your code?

    Please see the OSC Protocol Specification for details on how to construct a valid OSC packet - opensoundcontrol.org/introduction-osc

    There are several existing libraries for creating and sending OSC, however it is also quite simple to do yourself with reference to the specification.
Reply
  • 0 in reply to mikewoodld
    The descriptions we give in the Show Control guides are aimed at people using existing OSC applications like TouchOSC, MAX, QLab etc.

    We don't attempt to describe the underlying OSC protocol as that is defined by the OSC specification.

    The packets you've shown in Wireshark are not encoded as OSC, so definitely cannot work!
    - I guess that you're trying to assemble the raw OSC UDP packets in your code?

    Please see the OSC Protocol Specification for details on how to construct a valid OSC packet - opensoundcontrol.org/introduction-osc

    There are several existing libraries for creating and sending OSC, however it is also quite simple to do yourself with reference to the specification.
Children
Related

www.etcconnect.com