Strangest OSC behaviour I've ever seen

Armando

hello, I winder if anyone has experienced what I experienced today for the first time in my life in osc

I was connected to a dedicated router in DHCP like with other computer. So everybody was was on similar adresses 1923.168.10.xxx I was sending to 2 computers osc data. we triple checked ip adresses and port both manually and with Angry IP. All was fine from this point of voew. I was in Isadora and 2 other computers where on TouchDesigner. I am on a mac in Isadora and the 2 others were a mac and one a pc, all on TouchDesigner. The mac was receiving my OSC data but not the pc. But... the pc was receiving OSC from the other mac (both on TouchDesigner). Now, the problem seems to be the pc receving my osc because I was able=to send osc to the other mac on the network. Now, I do not know a lot on networking prefs on oc.

Has any of you experienced anything similar or have an idea ?

Thanks

Fred

@armando it’s a long shot but if you press enter when inputting the IP address in an send osc actor it adds a new line and the address is invalid. I do this a lot as I’m trained to press enter after inputting something. It will look totally normal in Isadora but will not work (a space will do the same I think)

Juriaan

@armando said:

1923.168.10.xxx

This is not a valid IP address, a IP address can only have 1-255 for each single field, separated by a dot, total of 4 sections

DillTheKraut

@juriaan

I might precise:

1-255 at first position

0-255 at second and third position

1-254 at last position

For easiest configuration set the subnet mask on all machines to

255.255.255.0

And be carefull, if you use a DHCP combined with fixed IP Adresses in a bigger network!

But usualy one can't set the IP wrong, as the OS will not except others. Therefore I guess it is a typo rather here or in the OSC control actor.

DusX

@armando said:

winder if anyone has experienced what I experienced today

Yes, I have had users in the past have issues getting OSC data into Touch. I don't remember the fix, it was something simple, like a forward slash at the end of an OSC address (or something like that). In the end it was always dealt with on the Touch side. It appeared that Isadora's behaviour was correct and consistent between platforms.

Armando

@ Dusx @juriaan @Fred @DillTheKraut. Sorry I just mistyped here in the forum (but not in izzy) Itas 192.168.10.XXX The proof being that the mac with Touchdesigneer was receiving OSC. Fred, thanks as always, I am aware of the carriage return as an invisible character that might render invalid an IP address like a space. But in my case, the mac was receiving the OSC values in Touch. That is why I am sure it must have been something else in the pc network prefs.... I'll give it another go.

DillTheKraut

@armando

It is difficult to find the real issue from here. I would follow a standard procedure with several test on Network, OS and software level.

two tests which come directly to my mind.

Check the Network connection between the TD PC and the sending Isadora Mac:
In the terminal (MacOS) / Command Window (Win), use the 'ping' command in both directions.
ping 192.168.10.x

If both work, go to the next step.

Start a different OSC software e.g. isadora on the TD PC, to see if the commands work there. If this is the case, some setting might be wrong in TD or the sending Izzi (like not matching OSC Port #).

I guess I don't need to say, check all settings, especially the sending and receiving port numbers.

Do I get this right:

Mac1 Izzy -> PC TD not working
Mac2 TD -> PC TD working
Mac1 Izzy -> Mac2 TD working

What about Mac2 Izzy -> PC TD?

Mac1 Izzy and Mac2 TD using the exact same OSC sending settings?

My test mentioned above would mean: Mac1 Izzy -> PC Izzy and maybe

Mac1 Izzy <- PC Izzy

Armando

@dillthekraut Thank a lot ! That would have been what I would have done (more or less) but I was in a production so I didn't have time and resources to test it in that way. I'll definitely look into it and report it here as soon as I can. Interesting case