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" 
> An: "Rick Snow" 
> 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" 
> An: pd-list@lists.iem.at, "Christof Ressi" 
> 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" 
> To: "Rick Snow" 
> Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" 
> 
> Subject: Re: [PD] Pduino sysex vs. OSC advice
> Message-ID:
>         
> 
> 
> 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" 
> An: "Christof 

Re: [PD] Deken for developers

[Chris McCormick]

Hi Julián,

On 17/06/16 06:26, Julián Villegas wrote:

I’m sorry if I missed this, but what’s the best approach for a developer to 
have her externals reachable in deken? I have several externals that I’d like 
to make available to the community but I don’t know how.


Great! I think there are two ways right now:

 1. Manually create a package (zip file) following the file naming 
scheme, and upload to pure-data.info - there is info about the filename 
format here: 
https://github.com/pure-data/deken/blob/master/developer/README.md#filename-format


 2. Use the deken developer tool to perform the packaging & upload for 
you: https://github.com/pure-data/deken/blob/master/developer/README.md


With option 2 you can download the script linked at the top of that page 
into your ~/bin folder, chmod 700 it, and run it to get started.


There was talk of a 'deken' target for the pd-lib-builder Makefile but I 
am not sure if that has been implemented yet and I couldn't find 
anything in the sources. Maybe Katja will have more info about where 
that is up to.


Cheers,

Chris.

--
http://mccormick.cx/

___
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]

> 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" 
An: pd-list@lists.iem.at, "Christof Ressi" 
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" 
To: "Rick Snow" 
Cc: "pd-list@lists.iem.at[pd-list@lists.iem.at]" 

Subject: Re: [PD] Pduino sysex vs. OSC advice
Message-ID:
        


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" 
An: "Christof Ressi" 
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 
 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 

[PD] Deken for developers

[Julián Villegas]

Hi list,

I’m sorry if I missed this, but what’s the best approach for a developer to 
have her externals reachable in deken? I have several externals that I’d like 
to make available to the community but I don’t know how.

Thanks,

Julian.






___
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

[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] pix_dump after pix_mask does not work properly

[cyrille henry]

hello,

if you send the beng during the gemchain interpretation, the 2 print are 
different.
i guess it will solve your problem.
cheer

c



Le 16/06/2016 18:38, mick mengucci a écrit :

Hallo list,
I have a problem in getting the pixels' values of two different images with 
[pix_dump].

The images are the output of two different [pix_mask] objects on the same 
original image.

What I get is the list of pixels' values of the original image.

I see IOhannes answered that [pix_mask] objects do not work "in chain", maybe 
that's why it does not work. If so, is there any workaround?
I include the files with the mask images in attachment.
I hope someone can explain this to me!

I run Xubuntu 14.04.4 LTS, with Pd 0.46.2, GEM: ver: 0.93.git 1d4d372

Thanks

--
mickmengucci.bandcamp.com 
facebook.com/mickmengucci3 
facebook.com/Labio.pt 
MISTURAPURA.NET 
pure mixture vibration since 1995


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



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

Re: [PD] Morse Code Translator / Decoder

[me.grimm]

hey thats great patrice thanks!

also... nice installation... love the water/air as code idea.

cheers
m

On Thu, Jun 16, 2016 at 8:24 AM, Jack  wrote:

> It is a little bit [OT], but here is an installation I co-produced with
> Cécile Babiole. It is a chat between two people based on a network
> working with water (coding en decoding (extended) Morse) :
> http://babiole.net/spip.php?article101
> It is now exhibited in Espace Gantner in Bourogne (East in France) :
>
> http://www.espacemultimediagantner.cg90.net/exposition/anarchronisme-machines-a-perturber-le-temps/
> ++
>
> Jack
>
>
>
> Le 15/06/2016 20:03, patrice colet a écrit :
> >
> >
> > Le 15/06/2016 à 19:57, Joel Matthys a écrit :
> >> Is [list-compare] from an external library? It's not in vanilla.
> >>
> > I forgot to put this in a subpatch, sorry for that, it's in [list-abs]
> >
> >
> >> Joel
> >>
> >> On 06/15/2016 12:25 PM, patrice colet wrote:
> >>>
> >>> Hello,
> >>>
> >>>  I've made such patch to decode termites hammering into morse.
> >>>
> >>>  It uses the process described by andy, and datastructure for storing
> >>> characters, it could also now be done with [text]
> >>>
> >>> I've made a version where [env] testes if there is sound amplitude or
> >>> not,
> >>>
> >>> and compare with templates stored into datastructure.
> >>>
> >>>  Attached is that version that should work with mjlib/morse and
> >>> latest pd-vanilla.
> >>>
> >>> Best,
> >>>
> >>> patco
> >>>
> >>>
> >>> Le 15/06/2016 à 15:34, Andy Farnell a écrit :
>  Yes did that once, but I lost it years ago (the
>  patch I mean)
> 
>  IIRC its not that hard.
> 
>  Use a [timer] and onset/tone detector,
>  and an array that looks up the next state.
>  You need a way to navigate a tree - a state machine
>  with 26 terminal nodes (36 if you want numbers)
>  and there are four symbols to transition states,
>  dot, dah, short space and long gap (between letters)
> 
>  The array is a 4-tree collapsed into a "Turing tape"
>  so you use the symbol to select the offset (jump)
>  to the next state (table index) based on the last
>  symbol. A long gap always resets the index to 0.
> 
>  cheers,
>  andy
> 
> 
>  On Tue, Jun 14, 2016 at 11:41:20AM -0400, me.grimm wrote:
> > Hello,
> >
> > Has anyone made a patch/abstraction to "decode" or translate morse
> code to
> > text? I see text->morse but not the other way around
> >
> > thanks!
> > m
> > ___
> > 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
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> >
> >
> >
> > ___
> > 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
>



-- 

m.e.grimm, m.f.a, ed.m.
syracuse u., tc3
megrimm.net

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

Re: [PD] Morse Code Translator / Decoder

[Jack]

It is a little bit [OT], but here is an installation I co-produced with
Cécile Babiole. It is a chat between two people based on a network
working with water (coding en decoding (extended) Morse) :
http://babiole.net/spip.php?article101
It is now exhibited in Espace Gantner in Bourogne (East in France) :
http://www.espacemultimediagantner.cg90.net/exposition/anarchronisme-machines-a-perturber-le-temps/
++

Jack



Le 15/06/2016 20:03, patrice colet a écrit :
> 
> 
> Le 15/06/2016 à 19:57, Joel Matthys a écrit :
>> Is [list-compare] from an external library? It's not in vanilla.
>>
> I forgot to put this in a subpatch, sorry for that, it's in [list-abs]
> 
> 
>> Joel
>>
>> On 06/15/2016 12:25 PM, patrice colet wrote:
>>>
>>> Hello,
>>>
>>>  I've made such patch to decode termites hammering into morse.
>>>
>>>  It uses the process described by andy, and datastructure for storing
>>> characters, it could also now be done with [text]
>>>
>>> I've made a version where [env] testes if there is sound amplitude or
>>> not,
>>>
>>> and compare with templates stored into datastructure.
>>>
>>>  Attached is that version that should work with mjlib/morse and
>>> latest pd-vanilla.
>>>
>>> Best,
>>>
>>> patco
>>>
>>>
>>> Le 15/06/2016 à 15:34, Andy Farnell a écrit :
 Yes did that once, but I lost it years ago (the 
 patch I mean)

 IIRC its not that hard.

 Use a [timer] and onset/tone detector,
 and an array that looks up the next state.
 You need a way to navigate a tree - a state machine
 with 26 terminal nodes (36 if you want numbers)
 and there are four symbols to transition states,
 dot, dah, short space and long gap (between letters)

 The array is a 4-tree collapsed into a "Turing tape"
 so you use the symbol to select the offset (jump) 
 to the next state (table index) based on the last
 symbol. A long gap always resets the index to 0. 

 cheers,
 andy


 On Tue, Jun 14, 2016 at 11:41:20AM -0400, me.grimm wrote:
> Hello,
>
> Has anyone made a patch/abstraction to "decode" or translate morse code to
> text? I see text->morse but not the other way around
>
> thanks!
> m
> ___
> 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
>>>
>>>
>>>
>>> ___
>>> 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
> 
> 
> 
> ___
> 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

[PD] [PD-announce] gigaverb~ update: version 0.2

[Marco Matteo Markidis]

Dear all,

I update gigaverb~. Now it is available via Deken. OS X 32-64 bit and Linux
64 bit versions are provided.
No Win version: however the source code and the makefile are present.

For any problem, just contact me.

Best regards,

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

Re: [PD] biquad and karplus-strong

[Julian Brooks]

Hey Alexandre,

I got sound that I liked really quickly out of your patch.
Surely a good didactic test.

Regards,

Julian

On 16 June 2016 at 07:26, Alexandre Torres Porres  wrote:

>
>
> 2016-06-15 5:09 GMT-03:00 Peter P. :
>
>> Orm's implementation of the random phase might also be cheaper than
>> your two fexpr~ for that part.
>
>
> it's just "expr~" not "fexpr~" ;)
>
>
>> You might not have to be conservative with CPU
>> usage in your case at all however.
>>
>
> nope, and I need to be more intuitive (as this is a didactic material) and
> I consider this to be "simpler" - subjective
>
>
>> It does work and might save cpu compared to fexpr~.
>>
>
> biquad~ is surely cheaper than fexpr~ !!!
>
>
>> In my case I am trying a textbook implementation for now.
>>
>
> yep, that's what I was going for in that example, what you think? If you
> have more remarks other than efficiency, I'd like to know.
>
> cheers
>
> ___
> 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] biquad and karplus-strong

[Alexandre Torres Porres]

2016-06-15 5:09 GMT-03:00 Peter P. :

> Orm's implementation of the random phase might also be cheaper than
> your two fexpr~ for that part.


it's just "expr~" not "fexpr~" ;)


> You might not have to be conservative with CPU
> usage in your case at all however.
>

nope, and I need to be more intuitive (as this is a didactic material) and
I consider this to be "simpler" - subjective


> It does work and might save cpu compared to fexpr~.
>

biquad~ is surely cheaper than fexpr~ !!!


> In my case I am trying a textbook implementation for now.
>

yep, that's what I was going for in that example, what you think? If you
have more remarks other than efficiency, I'd like to know.

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