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 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 requir

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

Re: [PD] Pduino sysex vs. OSC advice

[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 
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" 
An: Pd-List , "Rick Snow" 
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" 
An: "pd-list@lists.iem.at" 
Betreff: Re: [PD] Pduino sysex vs. OSC advice

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[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[https://lists.puredata.info/listinfo/pd-list]

_60_LEDs_OSC_HueSat_evenOdd_korr2.ino
Description: Binary data
___
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]

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" 
An: "pd-list@lists.iem.at" 
Betreff: Re: [PD] Pduino sysex vs. OSC advice


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




_60_LEDs_OSC_HueSat_evenOdd_korr_optimized.ino
Description: Binary data


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

[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] pmpd output in audio rate

[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 thing is that link length can be different of what you 
want.
in your example, all masses are in position 1, except the fixed mass (0).
so the link from 0 to 1 and 0 to 20 have a length of 1.
This cause unexpected problem in boundaries.

If you set masses position to 0, or send a message to set link length to 0, 
everything should be fine.


I see, it works now with mass position = 0. Then there is still one thing I don't 
understand, all the masses are actually fixed, and created with "mass sound 1 
...". But they still move to make sound?

I'll try to do a visualisation of the data, maybe I'll understand it better.


your patch made me realize a bug with negative length links in 1d simulation.
I just fixed it in svn.

cheers
c




One thing, there is still a high resonance, just like in the original [pmpd~] 
example. I imagine this is a limit of the synthesis method?

Best,

Joao

___
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] deken install user experience

[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 concerns still apply with above default install path? It seems
> pretty normal that applications do stuff there. Is anyone still against
> auto-creating? 

it seems indeed that the main obstacle for automatic directory creation
has gone with this new default user-specific search path.
if there is some consensus, i will happily re-enable the directory creation.
(but it seems that everybody has gone into sleep mode again, and will
only awake after the next release)

gfmadsr
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] deken install user experience

[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 install to the displayed directory
- no opens a directory chooser to select an alternative install target
- cancel aborts installation

this allows us to get rid of the "set install dir" button altogether.

mgfdsar
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] pmpd output in audio rate

[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  
different of what you want.

in your example, all masses are in position 1, except the fixed mass (0).
so the link from 0 to 1 and 0 to 20 have a length of 1.
This cause unexpected problem in boundaries.

If you set masses position to 0, or send a message to set link length to  
0, everything should be fine.


I see, it works now with mass position = 0. Then there is still one thing  
I don't understand, all the masses are actually fixed, and created with  
"mass sound 1 ...". But they still move to make sound?


I'll try to do a visualisation of the data, maybe I'll understand it  
better.



One thing, there is still a high resonance, just like in the original  
[pmpd~] example. I imagine this is a limit of the synthesis method?


Best,

Joao

___
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] pmpd output in audio rate

[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 what you 
want.
in your example, all masses are in position 1, except the fixed mass (0).
so the link from 0 to 1 and 0 to 20 have a length of 1.
This cause unexpected problem in boundaries.

If you set masses position to 0, or send a message to set link length to 0, 
everything should be fine.

cheers
c


Le 16/06/2016 00:27, João Pais a écrit :

Hello list - and Cyrille,

I'm trying to use [pmpd] to produce an audio rate output, but am having some 
unexpected results.

To test it, I'm adapting the patch 69_pmpd_for_audio, by replacing the pmpd 
content with the one from the patch 50_string~ (I think the adaptation is 
correct).
The reaction of the circuit seems to be ok, in that it produces a 
pizzicato-like sound. The difference is that there is a noise in the 500-1KHz 
area which isn't in the original [pmpd~] example. Is this noise from some bad 
patch adaptation, or is it a problem from using [pmpd]?

This patch attached uses some abstractions from the jmmmp library, you can 
download it through deken.

Best,

Joao


___
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