les_h
les_h

Reputation: 401

Receive an OSC message from Iannix in PD

Sending data from Iannix arrives to Pure Data in a way that causes routing problems.

[listen 57120<
[netreceive -u -b]
[oscparse]
[list trim]
[route cursor]
[route 1]

The data out of that appears to be a symbol with four numbers in it that is unparseable.

The left output of [route 1] should have given me information about the cursor ID 1. However, sending it to [unpack f f f f] does not output numbers.

Upvotes: 0

Views: 194

Answers (2)

uml&#228;ute
uml&#228;ute

Reputation: 31374

this seems to be a problem with your IanniX project itself.

the symbol right after the cursor-ID (or trigger-ID; or "whatever object"-ID) is to be the group-ID, which can be left empty in IanniX.

Pd's [print] object will happily print this empty symbol as an empty string (so it's hard to distinguish from "no atom").

The simple fix is, to assign a group ID to the cursor.

if this is not possible, you can just split the list right after the 1st element to ignore it:

[oscparse]
|
[list trim]
|
[route cursor]
|
[route 1]
|
[list split 1]
|      |
ign.   [print]

or just build your patch as if there was a group-ID and ignore it

[oscparse]
|
[list trim]
|
[route cursor trigger]
|
[route 1]
|
[unpack s f f ...]
|      |     |
ign.   x     y

Upvotes: 1

les_h
les_h

Reputation: 401

Something is weird about how Iannix sends data, but this can be worked around with the following:

[listen 57120<
[netreceive -u -b]
[oscparse]
[list trim]
[unpack s f s f f f f f f]
[pack s f f f f f f f] #(don't attach the second s)
[list trim]
[route cursor trigger]
# (the first element out from the first and second outlets of [route] is now the ID)

The list coming from [oscparse] has as it's third element some kind of empty symbol that causes problems if it ever becomes the first element in the list. Unpacking the list into individual elements and then repacking it without that empty symbol allows the data to be used normally.

Upvotes: 0

Related Questions