• State Verified Answer
  • Date
    mfo
  • Date
  • Replies 19 replies
  • Answers 1 answer
  • Subscribers 91 subscribers
  • Views 6663 views
  • Users 0 members are here

OSC - subscribe not working reliably

This is really frustrating. It is so complicated to get Pan/Tilt out of EOS.
It would be easy if .. Feature Request to get params
But as it stands the only way is to Subscribe to those parameters, then select a channel in question, then wait for the reply. Correct??

For me this only works if I leave pauses in-between the requests (~0.25sec) and if nothing else keeps EOS busy. As soon as I'm trying to pull Pan/Tilt (from a number of fixtures) while other processes happen, EOS does never reliably reply to all the requests. No matter how long the pauses I leave between those.
Isn't this a bug and can it be fixed?

Is there any other way to pull Pan/Tilt?

Parents
  • 0

    Are you trying to get Pan/Tilt values out from record targets? Or from a selected channel in live?

    Most of the OSC hooks are built around two things:

    1. Live values
    2. Record targets

    If you need values from inside a record target, yes, you need to get the channel list then iterate through it, storing the values. There isn't a sync method to go a layer deeper than the record target.

  • 0 in reply to sktusing

    Hi Sktusing,

    By record targets you mean Focus Palettes, Cues etc.?
    It's the same to me. I can also set those values before requesting them.

    The iterating-requesting-storing however should still work, even if EOS is doing other things in parallel, right? Or is dropped replies an expected behaviour?

  • 0 in reply to mfo

    Delivery of packets via UDP is not guaranteed.

    You might want to investigate a TCP connection. You can set a custom TCP port in the Show Control in System>Show Control>OSC>OSC TCP Server Ports, or use the default port for TCP of 3032.

  • 0 in reply to sktusing

    Thanks, I'll look into it!

    I've been wondering tho: if those missing replies are already missing in EOS' diagnose view (outgoing OSC) then it probably is not a UDP/TCP issue, isn't it?

  • 0 in reply to mfo

    Which packets are being dropped?

  • 0 in reply to sktusing

    I send "eos/user/0/newcmd" with "Chan xx#" for all channels (xx for channel number). The reply is a couple of infos (wheels, subscribed params, etc.).
    This reply sometimes randomly dropped.

  • 0 in reply to mfo

    I don't work for ETC, but OSC output is not guaranteed.

    "newcmd" is incredibly process heavy and depending on many factors (hardware, network, OSC input rate, phase of the moon, current outputs) I would not be surprised to see undesirable and inconsistent OSC output because of this. If you can get away with cmd, you might have better results.

    I would also recommend not using user 0 as it can be interrupted by macros and other things. You should create a user specifically for your OSC connection.

  • 0 in reply to sktusing

    Thanks for the tips!
    I tried both (different user, even iterating through users), but no avail. It remains unreliable.

  • 0 in reply to mfo

    So, I guess this qualifies as a bug report.
    How does one report bugs here (don't see a specific forum), any way to get an admin's attention?

  • 0 in reply to mfo

    What's the rate at which you're sending messages to Eos?

  • 0 in reply to mfo

    I'd try halving it until you stop losing packets.

    Just to point out, anything that uses /cmd or /newcmd assumes it will be posted to a command line and interacted with by a user. So try and stay within the speed at which a user would type and execute commands!

  • 0 in reply to sktusing

    Sadly I never found a reliable and practical solution for this.

    So, whoever manages to read until here and sees a need for a better solution for the above problem: please consider supporting this feature request for 3.2.0.

  • +1 in reply to mfo

    Hi   in 3.2.0 (currently in open Beta) there is support for a command of /eos/get/params/<channel> which replies like this:

    [ 12:00:03 ] [12:00:03] OUT [10.101.255.255:8000] [OSC Packet] /eos/get/params/1
    [ 12:00:03 ] [12:00:03] IN [10.101.2.99:8001] [OSC Packet] /eos/out/get/params/1, ETC Fixtures(s), Releve Spot Direct(s), Intens(s), 55.000(f), 0.000(f), 100.000(f), Pan(s), 139.000(f), -270.000(f), 270.000(f), Tilt(s), 72.000(f), -135.000(f), 135.000(f), X Focus(s), 0.000(f), -1000.000(f), 1000.000(f), Y Focus(s), 0.000(f), -1000.000(f), 1000.000(f), Z Focus(s), 0.000(f), -1000.000(f), 1000.000(f), Position MSpeed(s), 0.000(f), 0.000(f), 255.000(f), Red(s), 86.891(f), 0.000(f), 100.000(f), Lime(s), 100.000(f), 0.000(f), 100.000(f), Green(s), 0.000(f), 0.000(f), 100.000(f), Blue(s), 0.000(f), 0.000(f), 100.000(f), Hue(s), 0.000(f), 0.000(f), 360.000(f), Saturatn(s), 0.000(f), 0.000(f), 100.000(f), Gobo Ind/Spd(s), 0.000(f), -301.000(f), 301.000(f), Gobo Select(s), 0.500(f), 0.500(f), 1.500(f), Gobo Ind/Spd 2(s), 0.000(f), -100.000(f), 300.000(f), Gobo Select 2(s), 0.000(f), 0.000(f), 100.000(f), Iris(s), 100.000(f), 0.000(f), 100.000(f), Edge(s), 0.000(f), 0.000(f), 100.000(f), Zoom(s), 18.000(f), 18.000(f), 54.000(f), Shutter Strobe(s), 0.000(f), 0.000(f), 255.000(f), Diffusion(s), 0.000(f), 0.000(f), 100.000(f), Form MSpeed(s), 0.000(f), 0.000(f), 255.000(f), Beam MSpeed(s), 0.000(f), 0.000(f), 255.000(f)

    So for each parameter it gives the name, the current value, the min, and the max.

    This is not to say that it would not be good to support requesting individual parameters' levels as well.

    I will also caution that just like your method above, this returns the current Live levels, not any blind ones.

  • 0 in reply to Matt Pumplin

    Wow, amazing!! Thank you so much! Will check this out asap..

    (Individual parameter requests could help to reduce information overhead - but that would be icing the cake)

  • 0 in reply to mfo

    I agree that individual parameters will help much more, also the information which category to indicate if the channel is selected (category = 0)

  • 0 in reply to Matt Pumplin

    Tested and found working like a charm. So nice!

Reply Children
No Data

www.etcconnect.com