Iannix to TD --- OSCin CHOP/DAT

Hi
Admittedly, I am a newbie.

I seem to be missing something with the OSC messaging. Its probably something perfectly simple:

I am running a simple Iannix score. It consists of three cursors running at different speeds on a circular track. There should be three distinct messages being sent out of Iannix for each cursor:

The template for the messages reads as follows from Iannix:

osc://ip_out:port_out/cursor cursor_id cursor_group_id cursor_value_x cursor_value_y cursor_value_z cursor_xPos cursor_yPos cursor_zPos

The problem that I am having is that OSC in automatically separates the channels of the cursors on their parameters (yposition, speed etc.) as cursor 1 to 7. But it fails to parse the id of the cursor. With the three cursors that I have, OSC in should be generating 21 channels. Instead the cursors occupy the same channel and are not separated.

in OSCin DAT the syntax reads more clearly but I have no idea how to parse the in formation:

/cursor 2 “” 0.66307 0.134721 0. 5 0.8245516 -1.845429 0

My intuition tells me that OSC address scope should be able to parse this out, but I am really not sure how to implement the python command that will isolate the identity of the cursor. (you see… newbie…)

I’ve tried to make an identity for each cursor, that does get sent but it ends up in the same problem: the cursors just don’t separate into their channels.

the only way it works is if I change the message template in Iannix for each individual cursor. But then the whole point of iannix is that multiple cursors should be identified automatically.

any help would be appreciated

a sample of the actual messages beings sent out are this:

011:53:822 : osc://127.0.0.1:57120/cursor 4 0.865317 0.337079 0.5 1.8361 -0.833641 0
011:53:906 : osc://127.0.0.1:57120/cursor 2 0.650125 0.129241 0.5 0.760142 -1.87283 0
011:53:906 : osc://127.0.0.1:57120/cursor 3 0.807222 0.756154 0.5 1.54562 1.26174 0
011:53:906 : osc://127.0.0.1:57120/cursor 4 0.864827 0.335983 0.5 1.83365 -0.839117 0
011:53:906 : osc://127.0.0.1:57120/cursor 2 0.654748 0.131146 0.5 0.783255 -1.8633 0
011:53:906 : osc://127.0.0.1:57120/cursor 3 0.805292 0.758451 0.5 1.53598 1.27322 0
011:53:906 : osc://127.0.0.1:57120/cursor 4 0.864209 0.334616 0.5 1.83056 -0.845952 0
011:53:906 : osc://127.0.0.1:57120/cursor 2 0.658612 0.132791 0.5 0.802577 -1.85508 0
011:53:906 : osc://127.0.0.1:57120/cursor 3 0.803658 0.760369 0.5 1.5278 1.28281 0
011:53:906 : osc://127.0.0.1:57120/cursor 4 0.863686 0.33347 0.5 1.82795 -0.851684 0
011:53:956 : osc://127.0.0.1:57120/cursor 2 0.663007 0.134721 0.5 0.824552 -1.84543 0
011:53:956 : osc://127.0.0.1:57120/cursor 3 0.801775 0.762549 0.5 1.51839 1.29371 0
011:53:956 : osc://127.0.0.1:57120/cursor 4 0.863084 0.332162 0.5 1.82494 -0.858225 0
011:53:956 : osc://127.0.0.1:57120/cursor 2 0.667015 0.136536 0.5 0.844592 -1.83635 0
011:53:956 : osc://127.0.0.1:57120/cursor 3 0.800036 0.764535 0.5 1.5097 1.30364 0
011:53:956 : osc://127.0.0.1:57120/cursor 4 0.862529 0.330965 0.5 1.82216 -0.864211 0
011:54:002 : osc://127.0.0.1:57120/cursor 2 0.672268 0.138996 0.5 0.870855 -1.82405 0

The issue is that the OSC In CHOP doesn’t know that the cursor_id is an identifier to split these messages into different sets of channels. The only ‘identifier’ it’s getting is the OSC address, ‘cursor’, so it’s making 7 channels named ‘cursor’. When the next message comes in with a different ID it has same ‘cursor’ address so it just replaces the current channels.
The OSC In DAT does seem like the proper way do handle this particular case. In the new experimental build if you turn on ‘Split Messages Into Columns’, I think this puts the messages in the format that you can parse easier. Let me know if this doesn’t help.