|
Bug in OSC module makes it unusable
Patrick Jost [6 posts] |
9 year
|
Hello
There seems to be a bug in the OSC_Send variable module.
Im using it together with the Object Recognition module.
It sends out the variables properly the first time it recognise an object. after tracking of that object is lost and the object is recognised again, the osc module doesnt send out the variables/osc attributes any longer.
changing quickly the variable type on osc modules gui, makes the variables sent out again, as long the object is tracked.
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Yes, there was an issue with an empty array (such as that created by the OR module) would stop other variables from being sent correctly. This has been corrected in the latest version (just uploaded) which you can now download. Let us know if you notice any other issues.
Thanks!
STeven.
|
|
|
|
Patrick Jost [6 posts] |
9 year
|
thanks for the very fast fix... works fine now...
actually theres another little issue, not really sure if its a bug...
im sending out the "Objects" variable, which seems to send out 15 arguments per detected object. i dont know exactly what each argument is, is there a description of this somewhere?
so far i found out that the first two arguments are x and y position of the object.
now the weird thing: when detecting a second object theres a new first argument per detected object and X and Y argument get shifted to second and third place.
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Thanks for checking the new version. Glad its now working.
If you look under the Variables section in
http://www.roborealm.com/help/Object_Recognition.php
that has a list of what each entry in the Objects array is. Does this seem to match what you are getting?
STeven.
|
|
|
|
Patrick Jost [6 posts] |
9 year
|
thanks. should have took a closer look in the documentation.
ok it looks like when sending the array out via osc theres some shifting within the array going on.
when theres just one object detected, the array starts with index 1 "Point 1 X coordinate" while index 14 "Length of path" gives an empty argument. index 0 "Match Confidence 0-100" is missing.
as soon as more than one object is detected the array starts as it should with match confidence and everything is at the right place.
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Could you attach your robofile just for the OSC module? We'd like to see how that is configured as we don't seen anything obvious so we need to narrow down where the problem is happening.
I assume if you add the Watch_Variables module and see the Objects array that is correct regardless of the number of objects found? Just trying to ensure if the problem is with the OSC module (more likely) or the Object Recognition module.
It could be that the variable sent just before/after the OBJECT array is where the actual problem is.
Thanks!
STeven.
|
|
|
|
Patrick Jost [6 posts] |
9 year
|
hello
yes, "watch variables" shows it correct all the time.
i attached two screenshots of my setup (with one and two objects tracked).
in the zip you find the .robo file plus the receiver patch for vvvv.
 
 RR_OSC_VVVV.zip
|
|
|
|
Patrick Jost [6 posts] |
9 year
|
i tested with another osc receiver just to make sure the problem doesnt occur in vvvvs oscdecoder.
so i tried with osc monitor: http://frieder-weiss.de/OSC/index.html
and got the same result as in vvvv.
theres one interesting thing i oberved. when tracking just one object i got something like
,iiiiiiiiiiiiiiiM
as typetags on the receiver side. so its 15 ints followed by a capital character, they can be also something like "L,I,M" etc...
when tracking two objects i got:
,iiiiiiiiiiiiiiiiiiiiiiiiiiiiii
the capital character is not in the end.
maybe that helps to track down the problem.
best regards
patrick
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Patrick,
Thanks, having the test case is what we needed. Turns out that there was a padding issue with the OSC message. The data is sent in groups of 4 bytes. Even if the data fits into a 4 byte alignment one still needs to send an extra 4 bytes. Its an interpretation of what alignment means ... which was easily overlooked.
A single object fit into the 4 byte alignment exactly ... but was missing an extra 4 bytes according to the OSC alignment.
The latest version should have this fixed.
STeven.
|
|
|
|
Patrick Jost [6 posts] |
9 year
|
super, works now perfectly!
well nearly theres one little issue, ...setting variable type to automatics gives weird values which dont make sense...
setting the type to integer, string or float works perfectly, so its not really a problem.
|
|
|
|
Steven Gentner from United States [1446 posts] |
9 year
|
Thanks, I think we found the issue to that one too. There was also a correction to the bundle size that can get incorrectly reported. I'd recommend downloading again just to have those two new fixes aswell.
STeven.
|
|
This Thread
