Hi list.
I have a working mrpeach OSC patch which links a motion capture system (Captury) to Pd. I have no control over the message format being sent from the mocap software. The software requires to subscribe to every bone before that one is sent.
In mrpeach osc objects the subscription works like this:
[connect {IP} {port}( | | [send /subscribe/@/bllender/Root/vector( | | | [packOSC] |/ [udpsend]
I expected the vanilla version of this to be this:
[connect {IP} {port}( | | [symbol vector( | | | [oscformat -f sssss subscribe @ blender Root] | | | [list prepend send] | | | [list trim] |/ [netsend -u -b]
I also tried variations of that but could not get subscribed to the mocap system. Is the @ symbol an issue for vanilla OSC? It acts like a wildcard for any value in this case. If different people are registered each would have an assigned name instead of the @.
The same issue is at the receiving end to get the data.
mrpeach version (works):
[udpreceive {port}] | [unpackOSC] | [route /@/blender/Root/vector] | [unpack f f f] | [nbx]
my vanilla OSC version is not working:
[netreceive {port} 1] | [oscparse] | [route @] | [route blender] | [route Root] | [route vector] | [unpack f f f] | [nbx]
Any clues what could be wrong?
Note: "blender" in the osc path just refers to the skeleton standard used, there is no blender involved.
It's not an urgent matter, I can live with a working mrpeach implementation just fine, I was simply thinking to reduce the number of dependencies from 1 to 0 would be neat and was astonished that I could not do in vanilla what was possible with mrpeach.
m.
On Fri, 2018-11-23 at 22:37 +0100, Max wrote:
[symbol vector( | [oscformat -f sssss subscribe @ blender Root]
Try this:
[bang( | [oscformat subscribe @ blender Root vector]
It should give you the byte-identical result as [packOSC] output.
[netreceive {port} 1]
That's ok if you expect FUDI messages from UDP. But you want binary output as lists of floats. Use:
[netreceive -u -b {port} ]
If that still doesn't work, then you might post the raw output from [netreive] of an incoming OSC packet here. This will help analyze what's going on.
Roman
It works! ♥ Thank you Roman ♥
On 24.11.18 01:32, Roman Haefeli wrote:
On Fri, 2018-11-23 at 22:37 +0100, Max wrote:
[symbol vector( | [oscformat -f sssss subscribe @ blender Root]
Try this:
[bang( | [oscformat subscribe @ blender Root vector]
It should give you the byte-identical result as [packOSC] output.
[netreceive {port} 1]
That's ok if you expect FUDI messages from UDP. But you want binary output as lists of floats. Use:
[netreceive -u -b {port} ]
If that still doesn't work, then you might post the raw output from [netreive] of an incoming OSC packet here. This will help analyze what's going on.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list