Hi,
I've been using mrpeach
[packOSC]
|
[udpsend]
what is the equivalent of this using [netsend]?
-
netsend
-
solved this... was able to install mrpeach on raspberrypi 3 using...
apt-cache search "^pd-"
sudo apt-get install pd-libraryname
as suggested here:
https://forum.pdpatchrepo.info/topic/9741/pure-data-on-raspian-weezy-jessie/5and got packOSC from here:
https://github.com/pd-l2ork/pd/tree/master/externals/mrpeach/osc -
Hi,
If you want to use vanilla objects only:
[oscformat]
|
[netsend]If you look for vanilla objects, click on "List of objects..." from the "Help" menu. There is a section for OSC, MIDI, ect.
Cheers -
hey thanks.
i haven't had much luck with that option.
i get the following error messages.
oscformat: no method for (message contents)i am fine with using mrpeach but was unsure it would work on the pi.
would be great to figure out what i am doing wrong in the case of netsend though.
-
Your message should be a list. But in Pd, a set of values (string, float) is only interpreted as a list if it begins with a number or if it's prepend by the symbol list. So if you want something that works in all cases, you should use the [list] object before. And I made a mistake, to send a list via [netsend], the osc list should be prepended by the symbol send. So you can try:
| [list] | [oscformat ...] | [list prepend set] | [list trim] | [netsend ...]The ... are for the arguments, look at the helpfiles.
-
if i use packOSC to format the messages netsend works
messages
|
[packOSC]
|
[list prepend set]
|
[list trim]
|
[netsend -u -b]but not using oscformat
although adding list did take care of the error messages.i am sending messages to [packOSC] without creation arguments.
i have tried setting different arguments to [oscformat] by sending format messages to the object as described in the help files.
[format(
[format b(
[format fiiib(
[format ifisf( (this one causes pd to shutdown.)from the printout it looks like the [format( argument is correct
but for some reason is not registering correctly -
@youaresound There is a "bug" in [oscparse] that outputs floats from the message address as symbols..... but otherwise the vanilla objects should work.
It means that such message headers cannot be routed.
There is a "workaround".
Could you post your patch that is not working?
And also let us know if this works on your system...... ?
vanilla_bug_oscparse_solution.pd
David. -
Hi David,
Thank you.
the patch you posted works fine. -
the patch is kind of a mess right now..
it seems to be interpreting the messages differently.using oscparse:
oscparse: not an OSC message (no leading slash)
so added [oscformat /]here is the same message simultaneously. able to send but still not working correctly.
packOSC: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 115 0 115 111 117 114 99 101 0 0 108 111 99 97 108 104 111 115 116 0 0 0 oscformat: 47 0 0 0 44 115 115 115 0 0 0 0 47 116 117 105 111 47 50 68 99 117 114 0 115 111 117 114 99 101 0 0 108 111 99 97 108 104 111 115 116 0 0 0 packOSC: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 0 97 108 105 118 101 0 0 0 0 0 0 2 oscformat: 47 0 0 0 44 115 115 102 0 0 0 0 47 116 117 105 111 47 50 68 99 117 114 0 97 108 105 118 101 0 0 0 64 0 0 0 packOSC: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 102 102 102 102 102 0 0 0 0 115 101 116 0 0 0 0 3 62 190 118 201 62 210 110 152 192 160 0 8 192 160 0 8 193 134 205 159 oscformat: 47 0 0 0 44 115 115 102 102 102 102 102 102 0 0 0 47 116 117 105 111 47 50 68 99 117 114 0 115 101 116 0 64 64 0 0 62 190 118 201 62 210 110 152 192 160 0 8 192 160 0 8 193 134 205 159 packOSC: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 0 102 115 101 113 0 0 0 0 0 0 0 110 oscformat: 47 0 0 0 44 115 115 102 0 0 0 0 47 116 117 105 111 47 50 68 99 117 114 0 102 115 101 113 0 0 0 0 66 220 0 0 -
@youaresound It looks like you are trying to use mrpeach [packOSC] with [oscformat] so you are packing the message twice. I am not surprised that it is a mess.
We are completely nearly in the dark...... without seeing your patch.
I am not sure that the comma should be escaped for a valid blob message........?.... but it is probably correct.
What is the message you are trying to send?
David.
-
don't know where that coma is coming from as it is not part of the original message.
here is a simplified version. oscform.pd
i am at this point using packOSC with netsend
and comparing it to oscformat with netsendand trying to figure out how the message is being formatted differently by those two objects.
The actual patch is sending tuio messages to another source. (part of which you helped me with a while ago.)
but i am also using netreceive and oscparse to try to gauge what the differences are.
for some reason when sending with oscformat the message that arrives in oscparse keeps the / slashes but not when sent from packOSC.
netreceive-oscparse from packOSC-netsend
print: list tuio 2Dcur source localhost
print: list tuio 2Dcur alive 2
print: list tuio 2Dcur set 3 0.145 0.227 -5 -5 -16.8504
print: list tuio 2Dcur fseq 6netreceive-oscparse from oscformat-netsend
print: list /tuio/2Dcur source localhost
print: list /tuio/2Dcur alive 2
print: list /tuio/2Dcur set 3 0.745 0.807 -5 -5 -16.8504
print: list /tuio/2Dcur fseq 6 -
@youaresound "comma ss" just means "this message will be a blob with two symbols". It is inserted by [packOSC] or by [oscformat] to conform with OSC rules...... and make the message readable at the other end.
I have always used [packOSC] >> [udpsend]....... or [oscformat] >> [netsend] (always udp!)
The arguments for [netsend] are not the same in extended and vanilla.
You would have to use [packOSCstream] for tcp in extended.
What else?.... I will try to build a test patch..... but it might not be today.
David. -
just thanks and no worries.. i will post a more complete version of the patch when i get it cleaned up.
this link has some more info.
https://forum.pdpatchrepo.info/topic/10384/mrpeach-osc-and-raspberry/12
"With [oscformat] you can omit the slashes (but you can also include them if you like to keep the standard OSC protocol format). If you omit them, [oscformat] will add them behind the scenes."i've tried removing the slashes to see if that makes a difference (along with using multiple [oscformat] objects one for each part of the message), but there still seems to be an extra space in the messages sent from oscformat between list | tuio and only one space when sent from packOSC.
print: list tuio 2Dcur source localhost print: list tuio 2Dcur alive 2 print: list tuio 2Dcur set 3 0.745 0.807 -5 -5 -16.8504 print: list tuio 2Dcur fseq 6 print: list tuio 2Dcur source localhost print: list tuio 2Dcur alive 2 print: list tuio 2Dcur set 3 0.745 0.807 -5 -5 -16.8504 print: list tuio 2Dcur fseq 6 -
here is a version of the patch that includes how the messages are being built. edit-clean.pd
-
@youaresound The space seems to come from the slash in [oscformat /]. I have never used osc, so i don't know what this all means, but maybe just use something else as osc adress like [oscformat something] and get rid of the something address after receiving using [route something] for example?
On a side note, your [pd numbers] is doing nothing, i.e. input equals output...
-
you are right about the slashes. i replaced it with the first part of the message address tuio.
edit: you are right about the numbers too. don't know what i was doing wrong that was breaking the connection thanks
-
what i am trying to figure out is why the messages from oscformat and packOSC still don't match but print the same message and only the packOSC version works sending the tuio message.
are they formatting the floats differently?
this is the same message:
packOSC: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 0 102 115 101 113 0 0 0 0 0 0 0 3 oscformat: 47 116 117 105 111 0 0 0 44 115 115 102 0 0 0 0 50 68 99 117 114 0 0 0 102 115 101 113 0 0 0 0 64 64 0 0oscparse both:
print: list tuio 2Dcur fseq 3 print: list tuio 2Dcur fseq 3 -
@youaresound i suspect part of the reason is that you are sending different messages, so they are encoded differently. encoding is just exchanging the characters with their ASCII equivalent, see here: https://en.wikipedia.org/wiki/ASCII#Printable_characters
i wonder what happens if you use /tuio/2Dcur as osc address.
-
@youaresound This should help.
I have checked that messages are received correctly in extended as well, and I have checked that the packets are exactly the same as those sent by [packOSC].
cleaner.pd
David.
-
thank you both for looking at this... i now have a bit better understanding. i am still not sure why the messages are being encoded differently.
i am including an edit of the cleaner patch. that prints the same message coming from each object. here is each message side by side.
the first one is exactly the same but the others aren't.
parse: list tuio 2Dcur source localhost pack: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 115 0 115 111 117 114 99 101 0 0 108 111 99 97 108 104 111 115 116 0 0 0 form: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 115 0 115 111 117 114 99 101 0 0 108 111 99 97 108 104 111 115 116 0 0 0 parse: list tuio 2Dcur alive 9 pack: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 0 97 108 105 118 101 0 0 0 0 0 0 9 form: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 102 0 97 108 105 118 101 0 0 0 65 16 0 0 parse: list tuio 2Dcur set 1 2 3 4 5 6 pack: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 105 105 105 105 105 0 0 0 0 115 101 116 0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0 4 0 0 0 5 0 0 0 6 form: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 102 102 102 102 102 102 0 0 0 0 115 101 116 0 63 128 0 0 64 0 0 0 64 64 0 0 64 128 0 0 64 160 0 0 64 192 0 0 parse: list tuio 2Dcur fseq 15 pack: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 105 0 102 115 101 113 0 0 0 0 0 0 0 15 form: 47 116 117 105 111 47 50 68 99 117 114 0 44 115 102 0 102 115 101 113 0 0 0 0 65 112 0 0 -
@youaresound This seems to happen because no format is given. If you give the "format si" for the message "alive 9" you get the same result as with packOSC. "format si" means the message contains one string (s) and one integer (i).
