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 Reply Children
  • What's the rate at which you're sending messages to Eos?

  • 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!

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

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

  • 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)

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

  • Tested and found working like a charm. So nice!

Related