The changes in OSC made in 3.1 are not documented. This should done in the next revision, or a separate manual for Show Control.
We did add some OSC content for v3.1.0, but you are correct that other content is missing. Our apologies for that - we will try to get it included for v3.1.1.
New documentation for v3.1.0:
- XYZ Coordinates: https://www.etcconnect.com/webdocs/Controls/EosFamilyOnlineHelp/en-us/Default.htm#32_Show_Control/10_Open_Sound_Control_(OSC)/Supported_OSC_Input/OSC_XYZ.htm
(for example, if Chan 1 is a moving light,
Sets channel 1 to aim at position X=1m, Y=2m, Z=3m)
- staging mode: https://www.etcconnect.com/webdocs/Controls/EosFamilyOnlineHelp/en-us/Default.htm#32_Show_Control/10_Open_Sound_Control_(OSC)/Supported_OSC_Input/OSC_Staging_Mode.htm
- dedicated third-party TCP server port 3037: https://www.etcconnect.com/webdocs/Controls/EosFamilyOnlineHelp/en-us/Default.htm#31_Eos_Configuration_Utility/03_Network_Settings/Interface_Protocols.htm
- use of “=” to denote ETC-specific arguments : https://www.etcconnect.com/webdocs/Controls/EosFamilyOnlineHelp/en-us/Default.htm#32_Show_Control/10_Open_Sound_Control_(OSC)/Using_OSC.htm
Other new things that didn't make it to documentation.
- normalized fader levels (EOS-51565): Faders are now always 0.0 - 1.0 where 0.0 is min and 1.0 is max. So, a Global FX Fader may have a range of 0-200%: sending that fader to 0.75 gives a 150% output.
- OSC Get/Patch for Augment3d data (EOS-50738):
/Get Augment3d Information:
(These commands can return an FPE set of -1 at the end of the /position string; means no FPE set is not assigned.)
/Set Fixture Position:
(Six Arguments= pos_x, pos_y, pos_z, orientation_x, orientation_y, orientation_z)
(Separated by Commas and No Spaces)
/Get FPE information:
(FPE set of -1; means no FPE set is assigned.)
Thanks for the elaborate OSC support, Matt, much appreciated!!Sadly, when requesting augment3d position data I'm running into trouble.Sending e.g. "/eos/get/patch/1/1/augment3d/position" EOS Nomad (3.1.0 build 282, on Win10) replies:[with the UUID replaced for better readability] /eos/out/get/patch/1/1/list/0/21, -1(i), [...way more stuff...] /eos/out/get/patch/1/1/notes, -1(i), [UUID](s), (s) /eos/out/get/patch/1/1/augment3d/position, -1(i), [UUID](s), -4.000(d), 4.000(d), 2.000(d), 0.000(d), 0.000(d), 0.000(d), -1(i) /eos/out/get/patch/1/1//augment3d/beam, -1(i), [UUID](s), 0.000(f), (s), 4(i), 0.000(f), 0.000(f), 0.000(f), 0.000(f), 0.000(f), 0.000(f), 0.000(f), 0.000(f), (s), (s), 0.000(f), False(F)Issues here: * Only position is needed, but a massive overhead of data returned. Requesting this for some 30 fixtures is overkill.* Even the actual position message is rather wordy, due to the UUID * The "beam" information contains a double backslash (by design??).Would it be possible to get only the data that one can set through "/eos/set/patch/<chan>/augment3d/position" : the xyz coordinates + xyz orientations? That is really all that is needed.And I might be overstretching my luck here, but would it be possible to get those coordinates and orientations as Floats (f), instead of Doubles(d)? The software I'm using (vvvv) doesn't accept Double, which really is my core issue. So far anywhere floating point numbers are used in EOS those seem Float, why not have Float here too?! :)
OSC doesn't support Double, so I expect this is just a mistake.
Numbers are either Float32 or Int32
mfo said:Would it be possible to get only the data that one can set through "/eos/set/patch/<chan>/augment3d/position" : the xyz coordinates + xyz orientations? That is really all that is needed.
Please don't change the data that's being output from this command. Thanks!
The use of Doubles and the '//' appear to be oversights from when this feature was implemented for v3.1.0. They will be addressed in a future version of Eos software.
The UUID's are always supplied so that the receiving device can keep data in sync. The UUID is the "name" of the thing and is not changed when you change its position or channel assignment or other data. So, if channel 1 is changed to become channel 97, its position and other data aren't changed and the receiving device can stay in sync.
Thanks.(I get the reasoning behind of the UUID and the other data, and can see the use in some scenarios. But having worked as a developer many years ago, I'm also in mortal fear of data overhead in repeating multidimensional data :))
Just to clarify the record. Double is not a standard OSC type, but it is supported as a non-standard type. Many libraries don't support it though.