oksunp / vvopensource

Automatically exported from code.google.com/p/vvopensource
0 stars 0 forks source link

float not correctly parsed after string #17

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

(using maxmsp)
1. send message /beep 0.2 0.2
2. send message /beep ga 0.2

What is the expected output? What do you see instead?

message with string as 2nd arg does not parse the 3rd arg float correctly:

2011-02-14 15:25:45.489 osm_ipad2[5857:207] <OSCMessage: /beep-(
    "<OSCVal i 404>",
    "<OSCVal f 0.200000>",
    "<OSCVal f 0.200000>"
)>
2011-02-14 15:25:58.211 osm_ipad2[5857:207] <OSCMessage: /beep-(
    "<OSCVal i 404>",
    "<OSCVal s \"ga\">",
    "<OSCVal f 0.000000>"
)>

What version of the product are you using? On what operating system?

lastest (downloaded 10 feb 2011) compiled iphoneOS library running in simulator

(same messages sent round-trip back into maxmsp works as expected, so the 
messages seem corrrectly built)

Original issue reported on code.google.com by b...@artificiel.org on 14 Feb 2011 at 8:31

GoogleCodeExporter commented 8 years ago
when i assemble the same message using VVOSC:

OSCMessage      *msg = [OSCMessage createWithAddress:@"/beep"];
[msg addInt:404];
[msg addString:@"ga"];
[msg addFloat:0.02];

...it sends/receives correctly:

/beep : (
    <OSCVal i 404>,
    <OSCVal s "ga">,
    <OSCVal f 0.020000>
)

your "steps to reproduce" involve spending several hundred dollars on another 
programming language- since i'm not going to do that, would you mind creating a 
standalone patch which sends that message to 127.0.0.1 on a free port (1234's 
probably fine) and sending it to me for testing?

Original comment by raycut...@gmail.com on 14 Feb 2011 at 9:09

GoogleCodeExporter commented 8 years ago
hello,
(i replied to google's email but not sure it went somewhere; here is it as a 
comment)

to test i added this to my receivedOSCMessage:

    [outPort sendThisPacket:[OSCPacket createWithContent:m]];

and i get back the broken packet. i can confirm the same behavior with the 
simulator and the device (iPad iOS 4.2.1) and that the same messages sent to 
the OSCTestApp (downloaded binary) work correctly.

i also tested a bit more, and the problem is actually: any stringValue will 
break any further values in the message. i tested it also with txosc (a twisted 
python module) you can get with python's easy install

% easy_install twisted
% easy_install txosc

then (actual paths depends on where easy_install puts the txosc stuff)

% /usr/local/bin/osc-send -H 127.0.0.1 -p 1234 /ceci cela .2
% /usr/local/bin/osc-send -H 127.0.0.1 -p 1234 /ceci .2 .2

i looked in the code and modified the offset of the tmpIndex pointer. maybe 
there's a more efficient way to code this , but it works for me!

            case 'S':           //  alternate type represented as an OSC-string
                tmpInt = -1;
                int try=-1;
                for (j=tmpIndex; (j<l) && (tmpInt == -1); ++j)  {
                    try++;
                    if (*((char *)b+j) == '\0') {
                        tmpInt = j-1;
                    }
                }
                //  according to the spec, if the contents of the OSC-string occupy the
                //  full "width" of the 4-byte-aligned struct that *is* OSC, then there's an entire
                //  4-byte-struct of '\0' to ensure that you know where that shit ends.
                //  of course, this means that i don't need to check for the modulus before applying it.

                oscValue = [OSCValue createWithString:[NSString stringWithCString:(char *)(b+tmpIndex) encoding:NSASCIIStringEncoding]];
                [msg addValue:oscValue];
                //tmpIndex = tmpInt+1;
                //tmpIndex = 4 - (tmpIndex % 4) + tmpIndex;
//ORIG              tmpIndex = tmpIndex + tmpInt + 1;
//ORIG              tmpIndex = ROUNDUP4(tmpIndex);
                tmpIndex = ROUNDUP4(tmpIndex+try);

                break;

thanks!

Original comment by b...@artificiel.org on 15 Feb 2011 at 11:31

GoogleCodeExporter commented 8 years ago
"i can confirm the same behavior with the simulator and the device (iPad iOS 
4.2.1) and that the same messages sent to the OSCTestApp (downloaded binary) 
work correctly."

the OSCTestApp is compiled from the current codebase.  the code you pasted into 
your last comment looks very, very old- it looks like you're using r68 or 
earlier.  here's the diff where it looks like i fixed this bug from last summer:

http://code.google.com/p/vvopensource/source/diff?spec=svn68&r=68&format=side&pa
th=/trunk/VVOSC/FrameworkSrc/OSCMessage.m

are you sure you're running the current version?  how did you obtain it?

Original comment by raycut...@gmail.com on 16 Feb 2011 at 12:15

GoogleCodeExporter commented 8 years ago

Original comment by raycut...@gmail.com on 17 Feb 2011 at 11:11