Thanks again Christof for pointing me in a promising direction. I have been working with the OSC tagging via slipenc and slipdec.
As of now I have fairly reliable communication between PD and the Arduino sketch using a version the patch you provided. I am able to reliably send messages and the sketch responds as I expect most of the time. However, when sending several faders simulaneously I get some glitching. Right now I am wondering if it has something to do with using OSC instead of the raw slip packages. I do get this message in the pd console but I'm not sure that it relates to the glitching: "slipdec: input packet longer than 1006"
I've included the pd patch and the arduino sketch if anyone wants to take a look. these work with a WS2812 led strip.
If it is a messaging issue using the raw slip packages as described here sounds promising:
"You can also make your own simple protocol where you define a certain character to signify the start or end of a message. But how do you know if it's not part of the data? SLIP uses escape sequences to handle this case. Two alternative solutions: a) work with fixed length messages and count bytes (not very safe) b) reduce the range of possible values for your data (e.g. 0-127, like MIDI) and reserve the rest for addressing (128-255). If you need a greater resolution for your values, just break them up into several bytes. This way, sending a single 16 bit integer would take 4 bytes (address, bit 14-15, bit 13-7, bit 0-6). "
I am a total noob when it comes to this... could you share an example?
Cheers, Rick
Message: 2 Date: Thu, 2 Jun 2016 19:38:51 +0200 From: "Christof Ressi" christof.ressi@gmx.at To: "Rick Snow" ricksnow@gmail.com Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] Pduino sysex vs. OSC advice Message-ID:
<trinity-add7278d-1946-4da0-b7d2-6db454348f09-1464889131559@3capp-gmx-bs34
Content-Type: text/plain; charset=UTF-8
am able to get the LED to light up using ArduinoTestOSC.pd.
But you can also receive the data from the analog pin, right? (random values, if nothing is connected to the pin)
"Packet size (#) not a multiple of 4: dropping packet"
I can vaguely remember this message. Does it happen all the time or just at the beginning? Does it happen if you close and open the serial device? It didn't cause any problem with me. Actually, the Processing version of ArduinoSLIPSerialToUDP has protection against sending unvalid OSC messages.
Gesendet: Donnerstag, 02. Juni 2016 um 18:00 Uhr Von: "Rick Snow" ricksnow@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] Pduino sysex vs. OSC advice
Thanks Christof (and Martin) for pointing me to the CNMAT library.
I did spend a bit of time with this library before posting to the list but the tutorial I looked at originally required the ethernet shield. Now I am giving the slipenc/slipdec + OSC functionality a try. The raw SLIP packages look promising as well though I unfamiliar with bitshifting at this point!
Christof, Your Arduino_Serial patches look very promising. Thanks for taking the time to make this and send my way! I've taken a look and after getting the mrpeach objects loaded correctly (and the object/message connections correctly reconnected) am able to get the LED to light up using ArduinoTestOSC.pd.
There are a lot of unpackOSC messages telling me things like "Packet size (#) not a multiple of 4: dropping packet" but I think this is not a big problem right?
Thanks again! Rick
On Wed, Jun 1, 2016 at 6:40 PM, Christof Ressi christof.ressi@gmx.at wrote:The CNMAT OSC library works well and I often used it with a serial connection. The documentation, however, is not so good and some of the examples are buggy. I attached some test sketches/patches I once made for a class presentation. The arduino sketch explains how to easily send and receive OSC messages via a serial connection (make sure you use the same baud rate on both sides!)
Although OSC is convenient, it can be a waste of ressources if you send lots of messages. I often work with raw SLIP packages instead, where the first byte is used for addressing and the other bytes are the actual data (using some bit shifting to break up integers into several bytes). In the arduino code, use SLIPSerial.read() to fill an array (instead of an OSC message) and interpret your data as needed.
You can also make your own simple protocol where you define a certain character to signify the start or end of a message. But how do you know if it's not part of the data? SLIP uses escape sequences to handle this case. Two alternative solutions: a) work with fixed length messages and count bytes (not very safe) b) reduce the range of possible values for your data (e.g. 0-127, like MIDI) and reserve the rest for addressing (128-255). If you need a greater resolution for your values, just break them up into several bytes. This way, sending a single 16 bit integer would take 4 bytes (address, bit 14-15, bit 13-7, bit 0-6).
Christof
Gesendet: Mittwoch, 01. Juni 2016 um 17:16 Uhr Von: "Martin Peach" <chakekatzil@gmail.com[chakekatzil@gmail.com]> An: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[ pd-list@lists.iem.at]> Betreff: Re: [PD] Pduino sysex vs. OSC advice
There's an OSC library for Arduino here: https://github.com/CNMAT/OSCUsing%5Bhttps://github.com/CNMAT/OSCUsing] SLIP it can communicate over serial line using [comport] on the Pd end. Martin
On Wed, Jun 1, 2016 at 10:29 AM, Rick Snow <ricksnow@gmail.com[ ricksnow@gmail.com][ricksnow@gmail.com[ricksnow@gmail.com]]> wrote:
Hello list!
I am looking for some advice on sending messages from PD to an Arduino sketch. Essentially, I plan to connect a mac to an Arduino via USB and control a large amount of variables within the Arduino sketch from PD.
Is using the sysex message with the [arduino] object message the way to go with this? How can I "tag" the messages so that they go to the correct variable in the arduino sketch? Is there a practical limit to the speed of such a system?
I am much more familiar with using OSC messaging between applications but when I looked into using OSC with Arduino it seemed like I needed to use an ethernet shield (instead of connect via usb) and I would rather not go that route unless absolutely necessary.
Any advice is much appreciated!
cheers, Rick _______________________________________________
On Thu, Jun 16, 2016 at 11:35 AM, Rick Snow ricksnow@gmail.com wrote:
Thanks again Christof for pointing me in a promising direction. I have been working with the OSC tagging via slipenc and slipdec.
As of now I have fairly reliable communication between PD and the Arduino sketch using a version the patch you provided. I am able to reliably send messages and the sketch responds as I expect most of the time. However, when sending several faders simulaneously I get some glitching. Right now I am wondering if it has something to do with using OSC instead of the raw slip packages. I do get this message in the pd console but I'm not sure that it relates to the glitching: "slipdec: input packet longer than 1006"
The default SLIP packet length is set n the source: #define MAX_SLIP 1006 /* maximum SLIP packet size */ You can set the maximum packet length by giving [slipdec] a creation argument, e.g. [slipdec 32768].
Martin
Arghhh, please ignore my last arduino sketches. I had too little sleep and I got confused by all the braces (was too lazy to copy the code into a decent editor).
You actually did your matching inside the right while loop ("while(SLIPSerial.available())"). But writing to the LEDs should happen outside because there's no need to update the LEDs for every OSC message. Better do it after all messages have been read. Attached is a 'corrected' and optimized version. Again, not tested.
Are you sending all faders simultanously all the time? In that case it makes more sense to send a single OSC message, containing all the fader values as a list. Then you can dispatch every value via its index with getInt(INDEX)
Gesendet: Freitag, 17. Juni 2016 um 01:28 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at, "Rick Snow" ricksnow@gmail.com Betreff: Re: [PD] Pduino sysex vs. OSC advice
Hi, I think there was a problem in your arduino code: you did the testing against the address outside the while loop, so you will only have access to the latest message. The point of the while loop is that it will keep reading new OSC messages till the buffer is empty. So do your matching *inside* the while loop, right after a new message has been filled. Also, since your if clauses are mutually exclusive, you should do 'else if', so it will stop testing once you got 'true'. I attached a corrected version. You can try it and see if it works now. Unfortunately I couldn't test it myself. I also did an optimized version, where I made an array fad[0] which gives you more flexibility and lets you do the matching with a simple for loop instead of chained if clauses. Again, not tested. For this kind of application, you probably wouldn't need OSC. The question how to handle the bitshifting in a MIDI style protocol has already been answered in this thread ;-) https://lists.puredata.info/pipermail/pd-list/2016-06/115160.html Christof
Gesendet: Donnerstag, 16. Juni 2016 um 22:58 Uhr Von: "Martin Peach" chakekatzil@gmail.com An: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] Pduino sysex vs. OSC advice
On Thu, Jun 16, 2016 at 11:35 AM, Rick Snow ricksnow@gmail.com wrote:
Thanks again Christof for pointing me in a promising direction. I have been working with the OSC tagging via slipenc and slipdec. As of now I have fairly reliable communication between PD and the Arduino sketch using a version the patch you provided. I am able to reliably send messages and the sketch responds as I expect most of the time. However, when sending several faders simulaneously I get some glitching. Right now I am wondering if it has something to do with using OSC instead of the raw slip packages. I do get this message in the pd console but I'm not sure that it relates to the glitching: "slipdec: input packet longer than 1006" The default SLIP packet length is set n the source: #define MAX_SLIP 1006 /* maximum SLIP packet size */ You can set the maximum packet length by giving [slipdec] a creation argument, e.g. [slipdec 32768].
Martin _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l... Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Thank you for spending so much time looking at this! Being new to this side of arduino I am learning a great deal.
I'm testing your ...._korr2.ino sketch. Viewing the serial monitor shows me the expected input from the faders in the pd patch. However, I get no response from the led strip. I commented out your original Serial.println (fad[0]); here:
char pattern[] = "/fad/0"; // "/fad/N" is better OSC style than "/fadN"
for (int i = 0; i < 9; ++i){
// change the number in the address to the current index.
// if you want it to work with numbers that have more than a single
digit you have to adapt the code pattern[5] = i + '0'; if (msg.fullMatch(pattern, 0)){ // then check if first item is an integer if (msg.isInt(0)){ // use the integer argument for controlling the led 0 fad[0] = (msg.getInt(0)); } //Serial.println (fad[0]); break; // jump out of for-loop } }
Then tried to print from within:
{ if (fad[2] >= 1){ for (int i = 0; i < 30; i += 2){ leds[i] = CHSV( fad[1], fad[0], fad[2]); } Serial.println (fad[1]); Serial.println (fad[2]); }
in order to test whether the values are passing to this point in the code. Nothing prints to the serial monitor when sending values from pd in this configuration. I don't know exactly how to test whether the sketch is passing the values to the strip. Any ideas?
I will work on adapting/testing some of the other sketches now as well.
Thanks again! Rick
On Thu, Jun 16, 2016 at 7:01 PM, Christof Ressi christof.ressi@gmx.at wrote:
Arghhh, please ignore my last arduino sketches. I had too little sleep and I got confused by all the braces (was too lazy to copy the code into a decent editor).
You actually did your matching inside the right while loop ("while(SLIPSerial.available())"). But writing to the LEDs should happen outside because there's no need to update the LEDs for every OSC message. Better do it after all messages have been read. Attached is a 'corrected' and optimized version. Again, not tested.
Are you sending all faders simultanously all the time? In that case it makes more sense to send a single OSC message, containing all the fader values as a list. Then you can dispatch every value via its index with getInt(INDEX)
Gesendet: Freitag, 17. Juni 2016 um 01:28 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: Pd-List pd-list@lists.iem.at, "Rick Snow" ricksnow@gmail.com Betreff: Re: [PD] Pduino sysex vs. OSC advice
Hi, I think there was a problem in your arduino code:
you did the testing against the address outside the while loop, so you will only have access to the latest message. The point of the while loop is that it will keep reading new OSC messages till the buffer is empty. So do your matching *inside* the while loop, right after a new message has been filled. Also, since your if clauses are mutually exclusive, you should do 'else if', so it will stop testing once you got 'true'. I attached a corrected version. You can try it and see if it works now. Unfortunately I couldn't test it myself.
I also did an optimized version, where I made an array fad[0] which gives you more flexibility and lets you do the matching with a simple for loop instead of chained if clauses. Again, not tested.
For this kind of application, you probably wouldn't need OSC. The question how to handle the bitshifting in a MIDI style protocol has already been answered in this thread ;-) https://lists.puredata.info/pipermail/pd-list/2016-06/115160.html
Chris tof
If it is a messaging issue using the raw slip packages as described here sounds promising:
Just to be clear: the MIDI style approach is already a functioning protocol and doesn't require SLIP packages, because you can work with the raw serial data. However, you could *instead* use raw SLIP packages, which is very similar in the way you handle values with higher resolution (bitshifting). advantage: 8-bit data instead of 7-bit. disadvantage: slightly more complex because of the escape characters.
Again the link for an bitshifting example: https://lists.puredata.info/pipermail/pd-list/2016-06/115160.html
Gesendet: Donnerstag, 16. Juni 2016 um 17:35 Uhr Von: "Rick Snow" ricksnow@gmail.com An: pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: Pduino sysex vs. OSC advice
Thanks again Christof for pointing me in a promising direction. I have been working with the OSC tagging via slipenc and slipdec. As of now I have fairly reliable communication between PD and the Arduino sketch using a version the patch you provided. I am able to reliably send messages and the sketch responds as I expect most of the time. However, when sending several faders simulaneously I get some glitching. Right now I am wondering if it has something to do with using OSC instead of the raw slip packages. I do get this message in the pd console but I'm not sure that it relates to the glitching: "slipdec: input packet longer than 1006" I've included the pd patch and the arduino sketch if anyone wants to take a look. these work with a WS2812 led strip. If it is a messaging issue using the raw slip packages as described here sounds promising: "You can also make your own simple protocol where you define a certain character to signify the start or end of a message. But how do you know if it's not part of the data? SLIP uses escape sequences to handle this case. Two alternative solutions:a) work with fixed length messages and count bytes (not very safe) b) reduce the range of possible values for your data (e.g. 0-127, like MIDI) and reserve the rest for addressing (128-255). If you need a greater resolution for your values, just break them up into several bytes. This way, sending a single 16 bit integer would take 4 bytes (address, bit 14-15, bit 13-7, bit 0-6). "
I am a total noob when it comes to this... could you share an example? Cheers, Rick ------------------------------
Message: 2 Date: Thu, 2 Jun 2016 19:38:51 +0200 From: "Christof Ressi" christof.ressi@gmx.at To: "Rick Snow" <ricksnow@gmail.com[ricksnow@gmail.com]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@lists.iem.at]> Subject: Re: [PD] Pduino sysex vs. OSC advice Message-ID: trinity-add7278d-1946-4da0-b7d2-6db454348f09-1464889131559@3capp-gmx-bs34
Content-Type: text/plain; charset=UTF-8
am able to get the LED to light up using ArduinoTestOSC.pd.
But you can also receive the data from the analog pin, right? (random values, if nothing is connected to the pin)
"Packet size (#) not a multiple of 4: dropping packet"
I can vaguely remember this message. Does it happen all the time or just at the beginning? Does it happen if you close and open the serial device? It didn't cause any problem with me. Actually, the Processing version of ArduinoSLIPSerialToUDP has protection against sending unvalid OSC messages.
Gesendet: Donnerstag, 02. Juni 2016 um 18:00 Uhr Von: "Rick Snow" <ricksnow@gmail.com[ricksnow@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: Re: [PD] Pduino sysex vs. OSC advice
Thanks Christof (and Martin) for pointing me to the CNMAT library. I did spend a bit of time with this library before posting to the list but the tutorial I looked at originally required the ethernet shield. Now I am giving the slipenc/slipdec + OSC functionality a try. The raw SLIP packages look promising as well though I unfamiliar with bitshifting at this point! Christof, Your Arduino_Serial patches look very promising. Thanks for taking the time to make this and send my way! I've taken a look and after getting the mrpeach objects loaded correctly (and the object/message connections correctly reconnected) am able to get the LED to light up using ArduinoTestOSC.pd. There are a lot of unpackOSC messages telling me things like "Packet size (#) not a multiple of 4: dropping packet" but I think this is not a big problem right? Thanks again! Rick On Wed, Jun 1, 2016 at 6:40 PM, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:The CNMAT OSC library works well and I often used it with a serial connection. The documentation, however, is not so good and some of the examples are buggy. I attached some test sketches/patches I once made for a class presentation. The arduino sketch explains how to easily send and receive OSC messages via a serial connection (make sure you use the same baud rate on both sides!)
Although OSC is convenient, it can be a waste of ressources if you send lots of messages. I often work with raw SLIP packages instead, where the first byte is used for addressing and the other bytes are the actual data (using some bit shifting to break up integers into several bytes). In the arduino code, use SLIPSerial.read() to fill an array (instead of an OSC message) and interpret your data as needed.
You can also make your own simple protocol where you define a certain character to signify the start or end of a message. But how do you know if it's not part of the data? SLIP uses escape sequences to handle this case. Two alternative solutions: a) work with fixed length messages and count bytes (not very safe) b) reduce the range of possible values for your data (e.g. 0-127, like MIDI) and reserve the rest for addressing (128-255). If you need a greater resolution for your values, just break them up into several bytes. This way, sending a single 16 bit integer would take 4 bytes (address, bit 14-15, bit 13-7, bit 0-6).
Christof
Gesendet: Mittwoch, 01. Juni 2016 um 17:16 Uhr Von: "Martin Peach" <chakekatzil@gmail.com[chakekatzil@gmail.com][chakekatzil@gmail.com[chakekatzil@gmail.com]]> An: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]> Betreff: Re: [PD] Pduino sysex vs. OSC advice
There's an OSC library for Arduino here: https://github.com/CNMAT/OSCUsing%5Bhttps://github.com/CNMAT/OSCUsing%5D%5Bh...] SLIP it can communicate over serial line using [comport] on the Pd end. Martin
On Wed, Jun 1, 2016 at 10:29 AM, Rick Snow <ricksnow@gmail.com[ricksnow@gmail.com][ricksnow@gmail.com[ricksnow@gmail.com]][ricksnow@gmail.com[ricksnow@gmail.com][ricksnow@gmail.com[ricksnow@gmail.com]]]> wrote:
Hello list! I am looking for some advice on sending messages from PD to an Arduino sketch. Essentially, I plan to connect a mac to an Arduino via USB and control a large amount of variables within the Arduino sketch from PD. Is using the sysex message with the [arduino] object message the way to go with this? How can I "tag" the messages so that they go to the correct variable in the arduino sketch? Is there a practical limit to the speed of such a system? I am much more familiar with using OSC messaging between applications but when I looked into using OSC with Arduino it seemed like I needed to use an ethernet shield (instead of connect via usb) and I would rather not go that route unless absolutely necessary. Any advice is much appreciated! cheers, Rick _______________________________________________
had a look at your pd patch. regarding the [slipdec] thing: inside your arduino code, you're printing your data with serialPrint(), but [slipdec] expects slip packages. so that's probably the reason it complains. It keeps accumulating bytes and therefore exceeds the maximum length.
My patch is actually meant to be a kind of router, building a bridge between the arduino and other programs (most of which can deal easier with OSC via UDP than via Serial). In your case, you can get rid of the whole local host thing and just directly send the osc messages via [slipenc] to [comport]. Just grab the things out of my patch you actually need and get rid of the rest - or use it in another window/instance.
I attached an example how to use raw SLIP packages. Just modify it to your needs and see if it works better (it's definitely faster). 'index' would be your fader number and 'value' is the value. So for every fader change you just have to send a list of two bytes (index + value) to [slipenc] and from there to [comport]
Gesendet: Freitag, 17. Juni 2016 um 02:27 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "Rick Snow" ricksnow@gmail.com Cc: pd-list@lists.iem.at Betreff: Re: [PD] Pduino sysex vs. OSC advice
If it is a messaging issue using the raw slip packages as described here sounds promising:
Just to be clear: the MIDI style approach is already a functioning protocol and doesn't require SLIP packages, because you can work with the raw serial data. However, you could *instead* use raw SLIP packages, which is very similar in the way you handle values with higher resolution (bitshifting). advantage: 8-bit data instead of 7-bit. disadvantage: slightly more complex because of the escape characters.
Again the link for an bitshifting example: https://lists.puredata.info/pipermail/pd-list/2016-06/115160.html
Gesendet: Donnerstag, 16. Juni 2016 um 17:35 Uhr Von: "Rick Snow" ricksnow@gmail.com An: pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: Pduino sysex vs. OSC advice
Thanks again Christof for pointing me in a promising direction. I have been working with the OSC tagging via slipenc and slipdec. As of now I have fairly reliable communication between PD and the Arduino sketch using a version the patch you provided. I am able to reliably send messages and the sketch responds as I expect most of the time. However, when sending several faders simulaneously I get some glitching. Right now I am wondering if it has something to do with using OSC instead of the raw slip packages. I do get this message in the pd console but I'm not sure that it relates to the glitching: "slipdec: input packet longer than 1006" I've included the pd patch and the arduino sketch if anyone wants to take a look. these work with a WS2812 led strip. If it is a messaging issue using the raw slip packages as described here sounds promising: "You can also make your own simple protocol where you define a certain character to signify the start or end of a message. But how do you know if it's not part of the data? SLIP uses escape sequences to handle this case. Two alternative solutions:a) work with fixed length messages and count bytes (not very safe) b) reduce the range of possible values for your data (e.g. 0-127, like MIDI) and reserve the rest for addressing (128-255). If you need a greater resolution for your values, just break them up into several bytes. This way, sending a single 16 bit integer would take 4 bytes (address, bit 14-15, bit 13-7, bit 0-6). "
I am a total noob when it comes to this... could you share an example? Cheers, Rick ------------------------------
Message: 2 Date: Thu, 2 Jun 2016 19:38:51 +0200 From: "Christof Ressi" christof.ressi@gmx.at To: "Rick Snow" <ricksnow@gmail.com[ricksnow@gmail.com]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@lists.iem.at]> Subject: Re: [PD] Pduino sysex vs. OSC advice Message-ID: trinity-add7278d-1946-4da0-b7d2-6db454348f09-1464889131559@3capp-gmx-bs34
Content-Type: text/plain; charset=UTF-8
am able to get the LED to light up using ArduinoTestOSC.pd.
But you can also receive the data from the analog pin, right? (random values, if nothing is connected to the pin)
"Packet size (#) not a multiple of 4: dropping packet"
I can vaguely remember this message. Does it happen all the time or just at the beginning? Does it happen if you close and open the serial device? It didn't cause any problem with me. Actually, the Processing version of ArduinoSLIPSerialToUDP has protection against sending unvalid OSC messages.
Gesendet: Donnerstag, 02. Juni 2016 um 18:00 Uhr Von: "Rick Snow" <ricksnow@gmail.com[ricksnow@gmail.com]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: Re: [PD] Pduino sysex vs. OSC advice
Thanks Christof (and Martin) for pointing me to the CNMAT library. I did spend a bit of time with this library before posting to the list but the tutorial I looked at originally required the ethernet shield. Now I am giving the slipenc/slipdec + OSC functionality a try. The raw SLIP packages look promising as well though I unfamiliar with bitshifting at this point! Christof, Your Arduino_Serial patches look very promising. Thanks for taking the time to make this and send my way! I've taken a look and after getting the mrpeach objects loaded correctly (and the object/message connections correctly reconnected) am able to get the LED to light up using ArduinoTestOSC.pd. There are a lot of unpackOSC messages telling me things like "Packet size (#) not a multiple of 4: dropping packet" but I think this is not a big problem right? Thanks again! Rick On Wed, Jun 1, 2016 at 6:40 PM, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:The CNMAT OSC library works well and I often used it with a serial connection. The documentation, however, is not so good and some of the examples are buggy. I attached some test sketches/patches I once made for a class presentation. The arduino sketch explains how to easily send and receive OSC messages via a serial connection (make sure you use the same baud rate on both sides!)
Although OSC is convenient, it can be a waste of ressources if you send lots of messages. I often work with raw SLIP packages instead, where the first byte is used for addressing and the other bytes are the actual data (using some bit shifting to break up integers into several bytes). In the arduino code, use SLIPSerial.read() to fill an array (instead of an OSC message) and interpret your data as needed.
You can also make your own simple protocol where you define a certain character to signify the start or end of a message. But how do you know if it's not part of the data? SLIP uses escape sequences to handle this case. Two alternative solutions: a) work with fixed length messages and count bytes (not very safe) b) reduce the range of possible values for your data (e.g. 0-127, like MIDI) and reserve the rest for addressing (128-255). If you need a greater resolution for your values, just break them up into several bytes. This way, sending a single 16 bit integer would take 4 bytes (address, bit 14-15, bit 13-7, bit 0-6).
Christof
Gesendet: Mittwoch, 01. Juni 2016 um 17:16 Uhr Von: "Martin Peach" <chakekatzil@gmail.com[chakekatzil@gmail.com][chakekatzil@gmail.com[chakekatzil@gmail.com]]> An: "pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]" <pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[pd-list@lists.iem.at]]> Betreff: Re: [PD] Pduino sysex vs. OSC advice
There's an OSC library for Arduino here: https://github.com/CNMAT/OSCUsing%5Bhttps://github.com/CNMAT/OSCUsing%5D%5Bh...] SLIP it can communicate over serial line using [comport] on the Pd end. Martin
On Wed, Jun 1, 2016 at 10:29 AM, Rick Snow <ricksnow@gmail.com[ricksnow@gmail.com][ricksnow@gmail.com[ricksnow@gmail.com]][ricksnow@gmail.com[ricksnow@gmail.com][ricksnow@gmail.com[ricksnow@gmail.com]]]> wrote:
Hello list! I am looking for some advice on sending messages from PD to an Arduino sketch. Essentially, I plan to connect a mac to an Arduino via USB and control a large amount of variables within the Arduino sketch from PD. Is using the sysex message with the [arduino] object message the way to go with this? How can I "tag" the messages so that they go to the correct variable in the arduino sketch? Is there a practical limit to the speed of such a system? I am much more familiar with using OSC messaging between applications but when I looked into using OSC with Arduino it seemed like I needed to use an ethernet shield (instead of connect via usb) and I would rather not go that route unless absolutely necessary. Any advice is much appreciated! cheers, Rick _______________________________________________
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Martin Peach -
Rick Snow