[SOLVED] OSC Multi Transmit Integer Problem
-
I have been going a little crazy trying to send a very simple OSC message from v 2.2.2, it seems only a message with an int payload of 0 goes through, any other value is not registered. I need to control when I send messages in a scene and also sometimes send the same message twice (as the parameter can be changed by other computers), so I have to use the multitransmit even though I am only sending one message with one value (the normal osc transmit actor misses a transmit trigger, and cannot send the same message twice- not sure why, the send note and send control for midi do have this capability, I would think behaviors should be consistent).
To do a test I have re-created the same messages with openframeworks and found they work perfectly.Here is a snippet of my onKeyPressed() OF code:if(key == '2'){ofxOscMessage m;m.setAddress("/atem/aux/1");m.addIntArg(6);sender.sendMessage(m);}if(key == '3'){ofxOscMessage m;m.setAddress("/atem/aux/1");m.addIntArg(7);sender.sendMessage(m);}The same function from Isadora using either the oscTransmit or oscMultiTransmit does not work.I have tried using the osc transmit and multi transmit in user actor and forcing int and float types, tried turning on and off type tags, but no joy. Whenever I send a 0 int payload the message is correct, when I send a 1 or any other int payload, the system I am communicating with does not respond. With the same setup and network, when I form the messages with OF it all works perfectly.No time right now for wireshark analysis....Any ideas if this is an already registered bug? If so any ideas on a version that works. For the first time in a while I went to use Izzy on a simple project but hit this wall that is a little embarrassing.Fred -
Dear @Fred,
I just created the same example message in Processing 2.2 and everything works as expected with integer messages. I would assume that Processing is pretty much a standard and bug-free in terms of the OSC messages it is sending or receiving, so I'm using that as an indication that Isadora is in fact also adhering to the standard.Is there something else you need to do with the OSC message to set it up, like enabling Type Tags? Why don't you attempt to send messages from OF and then take a snapshot of what appears in the Monitor window and post it here. Then we can analyze the actual raw data being sent to Isadora.In the attached .zip see**osc-test.izz** for the Isadora file used to test**osc-transmit-example-processing.txt** for an example of sending an integer to Isadora. (Click the black window to send)**osc-receive-processsing-example.txt** for an example of receiving integers from Isadora. Typical output in processing was### received an osc message. addrpattern: /atem/aux/1 typetag: i value: 66### received an osc message. addrpattern: /atem/aux/1 typetag: i value: 8### received an osc message. addrpattern: /atem/aux/1 typetag: i value: 43**osc-receive-monitor-window-output.png**: a picture of Isadora's Monitor Window when receiving integers from Processing, which shows that they are integers because of the ",i" type tag.Best Wishes,Mark -
Ok, I just did has a chance to analyse the packets with wireshark. The payload is sent as a float even when I have selected integer, and it is a strange float as it has no decimal places. Here is a screen shot of the capture, dI can send you the capture session but ny network is pretty busy while I am doing this....
I have also attached a screen shot of my user actor and you can see the property is set to integer.I assume there is a cast missing for these values. It would be great if you can do a similar packet analysis and check what is going on so I can confirm the bug. I am at a kind of critical point in this project and am not interested in creating a work around software just to create an OSC message, come monday I need to decide if I can use Izzy or not for this tour.
-
Dear Fred,
As I emailed you privately, I have tested this myself with Wireshark and Isadora is indeed outputting an integer. I think that maybe you connected the User Input first, and then change it to an integer after. In this situation, the mutable input has already mutated to a float, so the change would not take place. (Disconnecting the User Input and re-connecting it should solve that problem if that's what happened.)Please post here if you find out what's happening, but I really am confident that it works.Best Wishes,Mark -
Yes setting the type before I connected the user input did fix the problem and without a user actor the float to int also works. I find the fact that you can change the types after the user inputs are connected but it does not have an effect quite strange, maybe you this ability should be altered or removed once the connection is made.
All good and int32s are flying everywhere now. -
Dear @Fred + All,
Glad to hear my suggestions worked. With regard to your comment " I find the fact that you can change the types after the user inputs are connected but it does not have an effect quite strange"Yes, the fact that you can change the type of a connected User Input or Output is a known bug. You can actually change it something totally wrong, like a video input. It is a known bug that we will fix.But just for everyone's education: the input port (the dot) for mutable inputs are green when they are still mutable, meaning they are ready to change to a different type. A mutable input or output changes its type a at the moment you connect it, and will not change again until you disconnect all the links to that input or output. This is indicated by the fact that the input port becomes blue, to show that the port is no longer mutable.At that point the type will not change type until all input are disconnected. Once you disconnect all links, the port becomes green again to indicate that it is now mutable again.Best Wishes,Mark
