Re: [PD] Pduino sysex vs. OSC advice

2016-06-16 Thread 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

Re: [PD] Deken for developers

2016-06-16 Thread 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

Re: [PD] Pduino sysex vs. OSC advice

2016-06-16 Thread 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

Re: [PD] Pduino sysex vs. OSC advice

2016-06-16 Thread Christof Ressi
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

Re: [PD] Pduino sysex vs. OSC advice

2016-06-16 Thread Christof Ressi
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 *ins

[PD] Deken for developers

2016-06-16 Thread 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-l

Re: [PD] Pduino sysex vs. OSC advice

2016-06-16 Thread 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 pat

Re: [PD] pmpd output in audio rate

2016-06-16 Thread cyrille henry
Le 16/06/2016 19:49, João Pais a écrit : Hi, Cyrille, The pmpd* object initial link length is the creation length. this is diferent from the link object where length is manually specified. The good things about this is that the created structure is mostly stable after it's creation. The bad

Re: [PD] deken install user experience

2016-06-16 Thread IOhannes m zmölnig
On 06/13/2016 11:25 AM, Roman Haefeli wrote: > I believe yet all have agreed to ~/.local/lib/pd/extra as the default > install path (and most recent Deken uses it). more important: (upcoming) Pd-0.47-1 uses it > There was some concerns about creating directories without asking. Now, > do those co

Re: [PD] deken install user experience

2016-06-16 Thread IOhannes m zmölnig
On 06/15/2016 02:32 AM, Miller Puckette wrote: > It's working for me. I've taken teh liberty of adding an "OK/cancel" > confirnation that prints where the thing will get installed. nice idea. in the deken repository i've changed this slightly to a "Yes/No/Cancel" dialog: - yes proceeds to instal

Re: [PD] pmpd output in audio rate

2016-06-16 Thread João Pais
Hi, Cyrille, The pmpd* object initial link length is the creation length. this is diferent from the link object where length is manually specified. The good things about this is that the created structure is mostly stable after it's creation. The bad thing is that link length can be differen

Re: [PD] pix_dump after pix_mask does not work properly

2016-06-16 Thread 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 image

Re: [PD] Morse Code Translator / Decoder

2016-06-16 Thread 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 > w

Re: [PD] Morse Code Translator / Decoder

2016-06-16 Thread 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 Fra

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

2016-06-16 Thread 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 ___

Re: [PD] biquad and karplus-strong

2016-06-16 Thread 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 >

Re: [PD] pmpd output in audio rate

2016-06-16 Thread cyrille henry
hello Joao, The pmpd* object initial link length is the creation length. this is diferent from the link object where length is manually specified. The good things about this is that the created structure is mostly stable after it's creation. The bad thing is that link length can be different of