MIDI Kinetics Forum

My goal is to send the text of a Menu object's currently selected item. So, I've created a script object that is a child of my Menu object, with the trigger being On Expression and the expression being "selection". I would like the following script to work:
On my target, a Windows 7 app, I can see (with a debugger) that the OSC Bundle has problems. The last two characters of the string are missing and there's a malformed 2nd OSC Message with an invalid OSC address. So, some of the data is getting through, but there's corruption.

I tried putting the data parameter in braces. This doesn't work either. I know the problem is likely with oscout because I can use the text from getattribute to display on a Text object. Also, if I use string literals in the oscout call, then it works fine.

So, my last resort is to do crazy stuff like this, which works: But I might have dozens of items in the menu, with some long strings, too. I don't want to use so much error-prone script to accomplish this goal when it should take just one line of script.

Am I doing something wrong? Even if I am, I don't think oscout() should ever send corrupted data. Thanks in advance for any help anyone can provide.

Hi
I think it must be a network processing/ corruption issue . .
It seems to work fine on this end - MacOSX . ..
Also in your revised version, you should be able to use the menuItemText without recasting the value. i think . . .
Cheers
MM

Thanks, Macciza, for trying to help. In my revised version, I can't use menuItemText directly because there's some kind of problem with passing it into oscout(). oscout() will send string literals just fine, but not the results of my getattribute() call, so I had to resort to that horrible if-else script.

I attached a small *.jzml file which shows this bug. If you or someone at Liine could try it out, I'd appreciate it.

I'm using Lemur 3.2.3 on the iPad 3 with iOS 6.0.1. (The problem happens on iOS 5 with Lemur 3.2.2, also.)

I used Microsoft Network Monitor to catch this UDP packet that was sent to my Windows 7 computer. Please take note of the ASCII text that says "TestItem". This should be "TestItem1". So, with this particular test case, the last character is dropped from the OSC message's data. There's some kind of second partial OSC message that has the address "/TestMenu/selection", but if I prevent the selection object from sending messages (by setting its Target to 'none''), that doesn't help.

binary:

00 24 BE B8 4F 2A 98 FE 94 C0 B8 AE 08 00 45 00 00 80 C4 F6 00 00 40 11 31 52 C0 A8 01 70 C0 A8 01 64 1F 40 1F 40 00 6C 28 FA 23 62 75 6E 64 6C 65 00 00 00 00 00 00 00 00 01 00 00 00 30 2F 53 6F 75 6E 64 4D 69 78 52 65 73 6F 75 72 63 65 2F 46 61 64 65 72 73 2F 30 2F 47 72 6F 75 70 00 00 00 00 2C 73 00 00 54 65 73 74 49 74 65 6D 00 00 00 1C 2F 54 65 73 74 4D 65 6E 75 2F 73 65 6C 65 63 74 69 6F 6E 00 2C 66 00 00 00 00 00 00

ASCII:

.$¾¸O*?þ?À¸®..E..?Äö..@.1RÀ¨.pÀ¨.d.@.@.l(ú#bundle............0/SoundMixResource/Faders/0/Group....,s..TestItem..../TestMenu/selection.,f......

So, I think there's some kind of problem with sending the result of getattribute(getobject(),'items')[selection] directly to oscout(), which causes oscout() to send garbage data.

--Ron

Hi
Wish I had kept the version I drafted . . . But with a new Menu and your script copied over it works with default text . . .
But it does seem there is something a little unexpected happening in there - I will pass it on to be looked into . . .
It may be an issue with the parsing of the script or it's interpretation by oscout . .
Thanks
MM

Thanks, Macciza, for investigating this and passing this along.

I took the time to break down this UDP packet in more detail. It looks like the string value in this OSC Message is not being truncated properly. The OSC 1.0 specification says that strings have to be null terminated and have additional null bytes to round up the total string data size to be a multiple of 4 bytes.

What I'm seeing is that the string data sent by my script is being rounded *down* to the nearest multiple of 4 bytes and is not null-terminated. So, depending on the original length of the string, up to 3 characters at the end get chopped off. If your string happens to be a multiple of 4 already, you may not notice any problem. For example, here are the following strings for these menu items, in Lemur and then in my UDP packet.

TestItem ==> TestItem
TestItem1 ==> TestItem
TestItem22 ==> TestItem
TestItem333 ==> TestItem
TestItem4444 ==> TestItem4444

But even the correct ones are still not null-terminated which can cause problems in other software. The OSC standard says they should be null-terminated. http://opensoundcontrol.org/spec-1_0

--Ron