Hi,
I am using an AVRmini board to pass data from several sensors to pd via OSC (USB), and I can do it on Linux with the objects pd_OSCSerial [1].
Now I need to work on windows for a project, but this object isn´t available on it, do you know any object I can use instead?
I've tried using serialosc2udp as they say in the page with no luck.
Many Thanks,
Ricardo
[1] https://ccrma.stanford.edu/wiki/AVR#Communicating_with_Pd_via_OSC_over_USB
Why not using the solution they place there?
<quoting their wiki page> Windows
Unfortunately, these objects have not yet been compiled for Windows. Until they are, you can use a small utility program that receives incoming serial data and sends it to a network port as UDP data.
- First, download
serialosc2udp.ziphttp://ccrma.stanford.edu/courses/250a/pd/serialosc2udp.zip .
Copy the file serialosc2udp.exe to your C:\ccrma\bin
Open the Windows command window and Run from the command line:
"serialosc2udp.exe COM# localhost 999" where '#' is your serial com port number.
Shut down your firewall
In Pd, make sure you have the standard OSC objects installed. Create a
"dumpOSC" object with port "999" as the argument.
</quoting their wiki page>
Or you wanted a single object that could perform that in Windows?
<quoting their wiki page> Or, you can download the source from pd_OSCserial_src20070810.tar.gz<http://ccrma.stanford.edu/courses/250a/pd/pd_OSCserial_src20070810.tar.gz>. If you want to develop these objects at CCRMA with the subversion repository, you must belong to the pid group. E-mail gurevich (at) ccrma and carrlane (at) ccrma to request to be added to the group. </quoting their wiki page>
Or... you can always try to compile the source in windows and make the needed changes.
2010/5/12 Ricardo Dueñas Parada rduenasp@gmail.com
sing an AVRmini board to pass data from several sensors to pd via OSC (USB), and I can do it on Linux with the objects pd_OSCSerial
As I said, I've had no luck with that solution, the program seems to work, but no data gets pd.
Ricardo.
If you have a recent pd-extended [mrpeach/slipenc] and [slipdec] can be used to serialize an OSC packet.
Martin
Ricardo Dueñas Parada wrote:
Hi,
I am using an AVRmini board to pass data from several sensors to pd via OSC (USB), and I can do it on Linux with the objects pd_OSCSerial [1].
Now I need to work on windows for a project, but this object isnŽt available on it, do you know any object I can use instead?
I've tried using serialosc2udp as they say in the page with no luck.
Many Thanks,
Ricardo
[1] https://ccrma.stanford.edu/wiki/AVR#Communicating_with_Pd_via_OSC_over_USB
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Martin, that´s what I´m looking for, but I am getting an error when I connect the comport output to the slipdec input, pd crashes inmediately and closes.
Comport receives data fine, and slipdec makes his job too, but together pd crashes, is it a stable version?
Thanks,
Ricardo
Hi Ricardo, Well I didn't have chance to try it with [comport], but I suspect you need to make the output of [comport] into lists using the slip packet delimiter 192 and [list append] and [list prepend] as in the [list] examples. It should not crash Pd though, that's bad... Martin
From: rduenasp@gmail.com Date: Wed, 12 May 2010 16:05:36 -0500 Subject: Re: [PD] OSCSerial for windows To: martin.peach@sympatico.ca CC: pd-list@iem.at
Hi Martin, that´s what I´m looking for, but I am getting an error when I connect the comport output to the slipdec input, pd crashes inmediately and closes.
Comport receives data fine, and slipdec makes his job too, but together pd crashes, is it a stable version?
Thanks,
Ricardo
hello,
from experiencing osc packets with another program (I was manipulating simpleOSC for python 3), I've sent a bad bytes packet and then unpackOSC just crashed, I thought you might be interested to know, maybe an error message could save the pd session when it happens?
Patrice Colet - 06 32 66 03 57
----- "martin peach" martin.peach@sympatico.ca a écrit :
It should not crash Pd though, that's bad...
patko wrote:
hello,
from experiencing osc packets with another program (I was manipulating simpleOSC for python 3), I've sent a bad bytes packet and then unpackOSC just crashed, I thought you might be interested to know, maybe an error message could save the pd session when it happens?
So it's [unpackOSC] that crashes, not [slipdec]... [unpackOSC] shouldn't crash Pd either. I was unaware of that. Thanks for telling me, although a patch that reliably causes the crash would be nice to see. I find it amusing hat Pd is able to peg all of these advanced operating systems that are supposedly able to control themselves. It must be one of the biggest security threats around.
Martin
Patrice Colet - 06 32 66 03 57
----- "martin peach" martin.peach@sympatico.ca a écrit :
It should not crash Pd though, that's bad...
Hi Ricardo, Well I didn't have chance to try it with [comport], but I suspect you need to make the output of [comport] into lists using the slip packet delimiter 192 and [list append] and [list prepend] as in the [list] examples. It should not crash Pd though, that's bad... Martin
Hi Martin, I used [list preped] and [list append] as you said and now it works, thanks.
However, I am still getting crashes with the stream from comport (if I program the microcontroller to send messages every ~200ms, it works fine), I read a recent mail about unpackOSC, then I tested using just slipdec (still crashes)
Crashes occur if I send messages too fast, just putting a [metro 50] to a valid message in slipenc-help.pd or sending microcontroller messages every 10 - 50 ms, freezes pd, and eventually make it crash.
I don't know what should be the minimun time that slipdec needs to process a packet, I use the same settings that I use in Linux with serialIO, OpenSoundControl and OSCruote [1], in Linux it works pretty well even with shortes times.
Do you know if this difference could be related to the operative system?
Ricardo.
[1] https://ccrma.stanford.edu/wiki/AVR#Communicating_with_Pd_via_OSC_over_USB
Hi Ricardo, Well I didn't have chance to try it with [comport], but I suspect you need to make the output of [comport] into lists using the slip packet delimiter 192 and [list append] and [list prepend] as in the [list] examples. It should not crash Pd though, that's bad... Martin
Hi Martin, I used [list preped] and [list append] as you said and now it works, thanks.
Yes, but I think it should work with individual input bytes, I noticed that it's not checking the buffer for overflow in that case, so I will fix that today. I was getting crashes by feeding [slipdec] with random bytes.
However, I am still getting crashes with the stream from comport (if I program the microcontroller to send messages every ~200ms, it works fine), I read a recent mail about unpackOSC, then I tested using just slipdec (still crashes)
Crashes occur if I send messages too fast, just putting a [metro 50] to a valid message in slipenc-help.pd or sending microcontroller messages every 10 - 50 ms, freezes pd, and eventually make it crash.
Maybe it's a [print] object overloading? Trying to print thousands of numbers usually hangs Pd.
I don't know what should be the minimun time that slipdec needs to process a packet, I use the same settings that I use in Linux with serialIO, OpenSoundControl and OSCruote [1], in Linux it works pretty well even with shortes times.
It should be able to hold on to a partial message indefinitely, but at the moment if the message list isn't a complete SLIP packet it might not work properly.
Martin
-
Martin Peach -
martin.peach＠sympatico.ca
-
patko -
Pedro Lopes -
Ricardo Dueñas Parada