Re: [PD] Pduino sysex vs. OSC advice

[Christof Ressi]

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.re...@gmx.at>
> An: "Rick Snow" <ricks...@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" <ricks...@gmail.com>
> An: pd-list@lists.iem.at, "Christof Ressi" <christof.re...@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.re...@gmx.at>
> To: "Rick Snow" <ricks...@gmail.com[ricks...@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 reme

Re: [PD] Pduino sysex vs. OSC advice

[Christof Ressi]

> 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" <ricks...@gmail.com>
An: pd-list@lists.iem.at, "Christof Ressi" <christof.re...@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.re...@gmx.at>
To: "Rick Snow" <ricks...@gmail.com[ricks...@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" <ricks...@gmail.com[ricks...@gmail.com]>
An: "Christof Ressi" <christof.re...@gmx.at[christof.re...@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.re...@gmx.at[christof.re...@gmx.at]> wrote:The CNMAT OSC library 
works well and

Re: [PD] Pduino sysex vs. OSC advice

[Martin Peach]

On Thu, Jun 16, 2016 at 11:35 AM, Rick Snow  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

Re: [PD] Pduino sysex vs. OSC advice (Christof Ressi)

[jamal crawford]

hi list, Christof

THAT was very insightfull. big massive thanks. 

On Thu, Jun 2, 2016, at 06:58 PM, Christof Ressi wrote:
> Check this article as a starting point:
> https://en.wikipedia.org/wiki/Bit_manipulation
> 
> For breaking up and reassembling integers you only need bit shifting and
> bit masking. Bit masking is needed to get rid of unwanted bits. For
> example:
> 
> Mask some byte:
> 1 0 1 0 0 1 1 0 (your data)
> &
> 0 0 0 0 1 1 1 1 (your mask)
> =
> 0 0 0 0 0 1 1 0 (result)
> 
> How to make your mask:
> 
> (1 << 4) is 16 (0001)
> (1 << 4)-1 is 15 () - here you go!
> 
> So the formular for making a mask where the rightmost N bits are all 1 is
> 
> (1 << N)-1
> 
> 
> Now here's a simple example of how to break up a 16-bit integer into
> three 7-bit values:
> 
> unsigned char buf[3]; // buffer for three bytes
> int a = 1234; // your integer, in binary it's  0100 1101 0010
> const unsigned char m = (1 << 7)-1; // a 7-bit mask
> 
> a &= (1 << 16)-1; // clip beyond 16 bit, just to be sure
> 
> buf[0] = a & m; // get the 7 rightmost bit by masking, in this case 101
> 0010 (= 82)
> buf[1] = (a >> 7) & m; // shift 7 bits to the right and mask, in this
> case 000 1001 (= 9)
> buf[2] = (a >> 14) & m; // shift 2*7 bits to the right and mask, in this
> case 000  (= 0)
> 
> or with a loop:
> 
> for (int i = 0; i < 3; ++i){
> buf[i] = (a >> i*7) & m;
> }
> 
> Now the other way round:
> 
> unsigned char buf[3] = {82, 9, 0}; // integer 1234 broken up into three
> 7-bit values 
> int a = 0; // integer to be reassembled
> 
> a += (int) buf[0]; // just 82
> a += (int) buf[1] << 7; // 9 shifted 7 bits to the left is 1152
> a += (int) buf[2] << 14; // 0 shifted 14 bits to the left is 0
> 
> /* a is now 82 + 1152 = 1234 */
> 
> or with a loop:
> 
> for (int i = 0; i < 3; ++i){
> a += (int) buf[i] << i*7; // make sure to first cast the unsigned
> char (byte) to an integer before shifting it to the left!!!
> }
> 
> 
> As you see, working with 7-bit data is actually quite neat. Just check if
> incoming bytes are bigger than 127 to distinguish between 'system
> messages' and actual data. This way it's quite simple to build your own
> little protocol.
> 
> Christof
> 
> 
> 
> Gesendet: Donnerstag, 02. Juni 2016 um 14:53 Uhr
> Von: "jamal crawford" <three...@ml1.net>
> An: pd-list@lists.iem.at, danomat...@gmail.com
> Betreff: Re: [PD] Pduino sysex vs. OSC advice (Christof Ressi)
> 
> hi list
>  
> > 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).
>  
> >That’s a great point. Everyone complains about MIDI now (not enough range, 
> >etc) but it’s *perfect* for >what it was designed to do: send small event 
> >data quickly on much older, slower hardware. I little >bitmasking and away 
> >you go.
>  
> i second that! very neat point indeed. would it be to much to ask if
> anyone could clarify that bitmasking to a lower, non-programmers level?
> like sending 1234 with midi, how would you break it down bitwise?
>  
> thanks in advance
>  
> 
> ~/.jc
>  ___ Pd-list@lists.iem.at mailing 
> list UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


-- 
~/.jc

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pduino sysex vs. OSC advice

[Christof Ressi]

>> 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" <ricks...@gmail.com>
An: "Christof Ressi" <christof.re...@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.re...@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" <chakekat...@gmail.com[chakekat...@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[https://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 
<ricks...@gmail.com[ricks...@gmail.com][ricks...@gmail.com[ricks...@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[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]]
 mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list][https://list

Re: [PD] Pduino sysex vs. OSC advice (Christof Ressi)

[Christof Ressi]

Check this article as a starting point: 
https://en.wikipedia.org/wiki/Bit_manipulation

For breaking up and reassembling integers you only need bit shifting and bit 
masking. Bit masking is needed to get rid of unwanted bits. For example:

Mask some byte:
1 0 1 0 0 1 1 0 (your data)
&
0 0 0 0 1 1 1 1 (your mask)
=
0 0 0 0 0 1 1 0 (result)

How to make your mask:

(1 << 4) is 16 (0001)
(1 << 4)-1 is 15 () - here you go!

So the formular for making a mask where the rightmost N bits are all 1 is

(1 << N)-1


Now here's a simple example of how to break up a 16-bit integer into three 
7-bit values:

unsigned char buf[3]; // buffer for three bytes
int a = 1234; // your integer, in binary it's  0100 1101 0010
const unsigned char m = (1 << 7)-1; // a 7-bit mask

a &= (1 << 16)-1; // clip beyond 16 bit, just to be sure

buf[0] = a & m; // get the 7 rightmost bit by masking, in this case 101 0010 (= 
82)
buf[1] = (a >> 7) & m; // shift 7 bits to the right and mask, in this case 000 
1001 (= 9)
buf[2] = (a >> 14) & m; // shift 2*7 bits to the right and mask, in this case 
000  (= 0)

or with a loop:

for (int i = 0; i < 3; ++i){
buf[i] = (a >> i*7) & m;
}

Now the other way round:

unsigned char buf[3] = {82, 9, 0}; // integer 1234 broken up into three 7-bit 
values 
int a = 0; // integer to be reassembled

a += (int) buf[0]; // just 82
a += (int) buf[1] << 7; // 9 shifted 7 bits to the left is 1152
a += (int) buf[2] << 14; // 0 shifted 14 bits to the left is 0

/* a is now 82 + 1152 = 1234 */

or with a loop:

for (int i = 0; i < 3; ++i){
a += (int) buf[i] << i*7; // make sure to first cast the unsigned char 
(byte) to an integer before shifting it to the left!!!
}


As you see, working with 7-bit data is actually quite neat. Just check if 
incoming bytes are bigger than 127 to distinguish between 'system messages' and 
actual data. This way it's quite simple to build your own little protocol.

Christof



Gesendet: Donnerstag, 02. Juni 2016 um 14:53 Uhr
Von: "jamal crawford" <three...@ml1.net>
An: pd-list@lists.iem.at, danomat...@gmail.com
Betreff: Re: [PD] Pduino sysex vs. OSC advice (Christof Ressi)

hi list
 
> 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).
 
>That’s a great point. Everyone complains about MIDI now (not enough range, 
>etc) but it’s *perfect* for >what it was designed to do: send small event data 
>quickly on much older, slower hardware. I little >bitmasking and away you go.
 
i second that! very neat point indeed. would it be to much to ask if anyone 
could clarify that bitmasking to a lower, non-programmers level? like sending 
1234 with midi, how would you break it down bitwise?
 
thanks in advance
 

~/.jc
 ___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pduino sysex vs. OSC advice

[IOhannes m zmoelnig]

On 2016-06-02 16:51, Rick Snow wrote:
> Thanks for the heads up Dan!
> 
> I spent a bit of time with CmdMessenger yesterday and bumped into the old
> comma/semicolon in a pd message issue.  At least in the example sketches
> the serial communication needed a command tag and a value defined in the
> format : "command tag number, value number;"
> 
> I searched the pd forums for a solution to this but was unable to make
> anything work in the time I had to work on it.  I did end up looking at the
> rc library any2byte, byte2any a bit though and it looked like this might
> offer a solution.
> 
> Does anyone know if there is a way to use the comma and the semicolon in a
> pd message in order to send it to the comport effectively?

since you can pass raw bytes to [comport], you could just insert "44"
(resp. "59") at the relevant places.

fgamsdr
IOhannes




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pduino sysex vs. OSC advice

[Rick Snow]

Thanks for the heads up Dan!

I spent a bit of time with CmdMessenger yesterday and bumped into the old
comma/semicolon in a pd message issue.  At least in the example sketches
the serial communication needed a command tag and a value defined in the
format : "command tag number, value number;"

I searched the pd forums for a solution to this but was unable to make
anything work in the time I had to work on it.  I did end up looking at the
rc library any2byte, byte2any a bit though and it looked like this might
offer a solution.

Does anyone know if there is a way to use the comma and the semicolon in a
pd message in order to send it to the comport effectively?

cheers,
Rick


On Wed, Jun 1, 2016 at 1:58 PM, Dan Wilcox <danomat...@gmail.com> wrote:

> [sysex] is used for MIDI messaging and OSC is designed around
> network-based communication, hence the ethernet shield.
>
> What I think you want is simple serial communication which is essentially
> sending / reading raw byte values. I would look into something like
> http://playground.arduino.cc/Code/CmdMessenger.
>
> The basic idea is similar to OSC, a protocol which determines which bytes
> are what and how to read them back correctly on the other end. I’m sure you
> could implement the CmdMessanger protocol in Pd using the [list toSymbol],
> [list fromSymbol], [oscparse], & [oscformat] object, or roll your own.
>
> 
> Dan Wilcox
> @danomatika <https://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
> On Jun 1, 2016, at 8:29 AM, pd-list-requ...@lists.iem.at wrote:
>
> *From: *Rick Snow <ricks...@gmail.com>
> *Subject: **[PD] Pduino sysex vs. OSC advice*
> *Date: *June 1, 2016 at 8:29:16 AM MDT
> *To: *pd-list@lists.iem.at
>
>
> 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

Re: [PD] Pduino sysex vs. OSC advice (Christof Ressi)

[Alex Norman]

There are a few higher resolution values in the midi spec that you can use.. 
The bend value (one per channel, so 16 total assesses) is 14 bit and there are 
also nrpn messages which combine several control change messages to create a 
larger address and value space (14 bit). Or you can use sysex... I'm on a phone 
or I'd write some pseudo code for that...

On June 2, 2016 5:53:32 AM PDT, jamal crawford  wrote:
>hi list
> 
>> 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).
> 
>>That’s a great point. Everyone complains about MIDI now (not enough
>>range, etc) but it’s **perfect* *for >what it was designed to do: send
>>small event data quickly on much older, slower hardware. I little
>>>bitmasking and away you go.
> 
>i second that! very neat point indeed. would it be to much to ask if
>anyone could clarify that bitmasking to a lower, non-programmers level?
>like sending 1234 with midi, how would you break it down bitwise?
> 
>thanks in advance
> 
>~/.jc
> 
>
>
>
>
>___
>Pd-list@lists.iem.at mailing list
>UNSUBSCRIBE and account-management ->
>https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pduino sysex vs. OSC advice (Christof Ressi)

[jamal crawford]

hi list
 
> 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).
 
>That’s a great point. Everyone complains about MIDI now (not enough
>range, etc) but it’s **perfect* *for >what it was designed to do: send
>small event data quickly on much older, slower hardware. I little
>>bitmasking and away you go.
 
i second that! very neat point indeed. would it be to much to ask if
anyone could clarify that bitmasking to a lower, non-programmers level?
like sending 1234 with midi, how would you break it down bitwise?
 
thanks in advance
 
~/.jc
 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Pduino sysex vs. OSC advice

[Rick Snow]

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