• 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 12202 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. 

  • 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.
  • 0 in reply to Richard

    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

     

  • 0

    Hey Mike! Did you ever come up with a good Filemaker script to send OSC properly via MBS? I've been working on the same thing.

  • 0 in reply to jakedeg

    Hey Jake! In a way, yes. I've done a lot more with both OSC and Strings with FileMaker since this post was made - have learned a ton since then too which makes a lot of this post embarrassing to read now! 

    My FileMaker/MBS/OSC stuff relies on an intermediate Python program that  worked on for me where it takes the incoming OSC, filters it to only what I want, and then takes the arguments and slaps them on the end of one long string separated by forward slashes. Then, I can parse that string in FileMaker and say get the nth value between the nth set of "/ /" if that makes sense. 

    Trying to get OSC packets directly to MBS/FileMaker was a crapshoot. Some things worked, some didn't. There are also challenges with FileMaker being able to read all of the messages without hanging up. 

    I'm currently using this Eos>Python>MBS>FM connection to get groups, cues, and presets from the console for image capture purposes. FM queries the console for targets, then the console replies back. It's not perfect but it works. 

    It's kinda complicated to type up properly without visuals and examples. Next time I'm in the city maybe we can meet up for lunch and I'll show you?

  • 0 in reply to sktusing

    Sorry I'm late to the game but where do you insert the py script? In FM? In Eos? Can't seem to figure out how FM can see the OSC commands.

  • 0 in reply to LKairys

    It sits between Eos and FileMaker, acting as a translator. So it’s basically its own thing, listening to Eos and then forwarding data on to FileMaker (using the MBS plugins like a normal UDP listener) 

Related

www.etcconnect.com