Some OSC commands work, some don't.

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

# 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. 

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" ?

Same thing. Wireshark sees both of those as-entered but EOS doesn't see them at all.

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.

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.

ah, of course, good catch!

mike, this is a wireshark screenshot of an OSC message (please disregard the colored markings, they're from another project). wireshark clearly identifies it as OSC where yours is identified as a general UDP package

 

ah, of course, good catch!

mike, this is a wireshark screenshot of an OSC message (please disregard the colored markings, they're from another project). wireshark clearly identifies it as OSC where yours is identified as a general UDP package