OSC - subscribe not working reliably

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.

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?

I wouldn't expect dropped replies to be expected. Are you connected via UDP or TCP?

UDP. (Afaik OSC always goes via UDP.)

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.

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?

Which packets are being dropped?

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.

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.

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.

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

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?

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

42Hz.

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