Some OSC commands work, some don't.

Question

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.

Sammy · Answer

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/ - Allows you to change the "" 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.

Richard · Answer

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.

Some OSC commands work, some don't.

Top Replies