Receiving Osc to Channel

You can send a regular command line to Eos to turn off a channel:

/eos/cmd/chan/1/out/enter

If you send it to the console's user ID this will show up in the console's command line, if you send it to a different ID you can send these commands in the background.

But it’s not what I want to do…

My example wasn’t good

if I receive xyz position in osc from an another computer how I can link those data to a channel ?

Either the data coming in is already linked to the channel through the information in the OSC you're receiving, or you're sending the values to a console (technically to a user ID) that already has a channel selected.

The former would be preferred, it will probably process quite a bit faster since it doesn't have to go through the command line.

No it’s not linked. I just receive xyz parameters and I would like to find a way to connect these parameters to channels.

Someone in Etc France tell me to use /etc/wheel/ ….  

This still needs a selection by the user ID you're sending to.

You might want to look into a software like OSCRouter to reformat the incoming OSC string (e.g. add the channel number) before the console receives it.

Thanks I will check that 

I send Osc to the desk. But my out path string is not good. Cannot link a channel. 

In the out path I tried /eos/chan/1/xyz….

It’s not working ….

What application is sending the OSC? This looks wrong...

The app is kratos. It’s a tracking application. 
It’s send xyz position in Osc 

You shouldn't be using wheels. Instead, you should use: /eos/user/99/chan/<Channel_Number>/param/<Parameter_Name>/override=<Value>

This is more efficient for Eos than using the wheel command - it will also send the data as override data as opposed to manual values.

You can configure the OSC address in Kratos.

Are you sending via ADM-OSC, or via OSC? You need to send via OSC as ADM-OSC is specific a way of sending data via OSC. As eos moderator has said, it looks like the OSC is malformed in some manner.

The packets they're saying look wrong, they look normal to me as a human who doesn't read binary, but I can't see the end of the packet which is where the human-readable part normally is. I'm just seeing the typical binary stuff that's at the start of the packets. Nothing to be afraid of in a network packet. 

The key thing here is that OSC messages consist of 2 parts: address and argument. The ETC Eos documentation on the matter is extremely poor. "Address" tells Eos what the stuff is, and the "argument" is the stuff. So if you want to send Eos stuff that is X position, you need to use the "address" to say, hey, this stuff is for this channel for x position, and then your "argument" is the actual stuff, or the data, or the actual x position number that you want Eos to send to the light. 

In QLab, you separate address from argument with a simple space. So for example,

eos/newcmd Go_to_Cue Out 

or

Address: eos/newcmd

Argument: Go_to_Cue Out 

tells console to create new instance in command line and go to cue out. 

So for a similar use-case to yours, here is another example that is for x-focus:

/eos/chan/1/param/x_focus 1

sets channel 1 x focus to 1. For xyz position, I don't have that syntax in front of me, so you'll have to pull it up in the Eos documentation. WARNING: Unless they've fixed the documentation since I last complained, the documentation on OSC syntax is extremely confusing and downright misleading. It will tell you to format commands using an = sign. Don't do it. It won't work. Substitute = for space. If you can, pull it up on the website because the formatting on that version, as opposed to the in-console tab-100 one, is better, but still 90's level graphics and is very confusing still both in verbiage, terminology, and general, overall  communication. But that information is useful as long as you don't get hung up on the confusing stuff and remember to NOT use the = sign. They're lying about the = sign. An employee told me on here that the = sign verbiage is just supposed to be a placeholder, end user isn't supposed to actually type that, but if the true intent, that was left morbidly unclear for end user.

Another note, the examples above are for Qlab, but in other softwares like TouchOSC and my software, you have some cases of separate input fields for address and argument, and other cases where the user of the software is only responsible for directly providing the address while the argument is computed in the background (that might be your current case). In that case you just skip the part in the documentation that says = and beyond. 

The packets they're saying look wrong, they look normal to me as a human who doesn't read binary, but I can't see the end of the packet which is where the human-readable part normally is. I'm just seeing the typical binary stuff that's at the start of the packets. Nothing to be afraid of in a network packet. 

The key thing here is that OSC messages consist of 2 parts: address and argument. The ETC Eos documentation on the matter is extremely poor. "Address" tells Eos what the stuff is, and the "argument" is the stuff. So if you want to send Eos stuff that is X position, you need to use the "address" to say, hey, this stuff is for this channel for x position, and then your "argument" is the actual stuff, or the data, or the actual x position number that you want Eos to send to the light. 

In QLab, you separate address from argument with a simple space. So for example,

eos/newcmd Go_to_Cue Out 

or

Address: eos/newcmd

Argument: Go_to_Cue Out 

tells console to create new instance in command line and go to cue out. 

So for a similar use-case to yours, here is another example that is for x-focus:

/eos/chan/1/param/x_focus 1

sets channel 1 x focus to 1. For xyz position, I don't have that syntax in front of me, so you'll have to pull it up in the Eos documentation. WARNING: Unless they've fixed the documentation since I last complained, the documentation on OSC syntax is extremely confusing and downright misleading. It will tell you to format commands using an = sign. Don't do it. It won't work. Substitute = for space. If you can, pull it up on the website because the formatting on that version, as opposed to the in-console tab-100 one, is better, but still 90's level graphics and is very confusing still both in verbiage, terminology, and general, overall  communication. But that information is useful as long as you don't get hung up on the confusing stuff and remember to NOT use the = sign. They're lying about the = sign. An employee told me on here that the = sign verbiage is just supposed to be a placeholder, end user isn't supposed to actually type that, but if the true intent, that was left morbidly unclear for end user.

Another note, the examples above are for Qlab, but in other softwares like TouchOSC and my software, you have some cases of separate input fields for address and argument, and other cases where the user of the software is only responsible for directly providing the address while the argument is computed in the background (that might be your current case). In that case you just skip the part in the documentation that says = and beyond. 

You are correct. When typing out an "OSC Annotation" into various pieces of software there are different formats in the wild. Eos uses the equals/comma style where as others (QLab) uses spaces. I have written about this here