Re: [PD] Installing PD on OpenSUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-05-11 19:47, Martin Peach wrote: I removed the requirement for 5.1 in the makkefile, this was in January of this year. i think the OP is referring to Pd-extended 0.43.4 - Released 2013-01-25 and while january matches, the year is off by one :-) so the released Pd-extended sources are not at all up-to-date with the SVN. fgmasd IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIbBAEBCAAGBQJTcHQvAAoJELZQGcR/ejb4OgoP+PkPFwDqV3yjsPd2OLwufNGH FZ5khQKsXkjPbHSSOYZVUZeStb8f2mceBTyicv4UCcacJBorSnHQw/+WgTwtlJsb vjTGNOATWn5Gg3SSR21u8uCGEVNoNr1hJ//wzOiIxRkdQVIqt2TF2gciaIpGOvD7 YQii9n4sta3KXLx322MqTkiNDra0eE9y93H4IHyTmA2h1fcL0YK1cHeg7I8QOPnc N7Yw/ifj9ufvWJ21IF5XCq/QHmHv164OdXfuIlKmAsQ0lSDBzeP8jrtSGgQq85lf k8vUnYcXSfJjs2GB3QJgv+kl1Y6rOiWGagRzbWqbvv5L/IpgnD5aEChbR+vdhtnX 4XwYT/QM1h7L/zmoQVUV0lN6BNNGAUW7Wn/v3QZEHcDFrsJZtui/iZK9rZsz+M6E pgIWEj0FdmQYbM6pAHyRZKWea9XEceFVwdIVGiAid/rRDCdjAl0mvYQds1flVPv3 FbDrrOY/ix6k9H4pon9dAKXnmFcABFoOkaihaRVL28XeGiceJD2XRLLeP6mLQGg5 T4GM56+PtEdgGPg11RC7WsiHlvQ48/wNB51J/rnDmEXGhNoDKl5Mb5xnmiavxSxX 4DRuXiCczqKlcqNoNH4JNvdN4WIw3PJv7z3odY8VJ097NWhDbgelgBfunry5piyX ghi6T/ovuucvJovFZME= =8xJI -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best format for send/receive between iOS and libPD
thanks Miller and Rich for the help. We thought at first that it might be better to package all our pattern data together, but after reading what you guys have written, i can see that individual values should be the best way to go. We do have some arrays though, so that PdBase copyArray* will hopefully work for that. thanks again! Matt On Sun, May 11, 2014 at 10:44 AM, Rich E reakina...@gmail.com wrote: I'd second what Miller said, for a different reason though: every time you send a message from your app's main thread (the iOS / obj-c bits) into pd (the libpd bits), a mutex will lock because the audio thread runs on a different thread and needs to be synchronized. Breaking the lists down (not all the way down, just not one giant list) will mean that the synchronization takes less time, so less chance of dropping audio packets. Also, if you can, I'd store as much data as you can in pd arrays, and then send across lookup information instead. Pd arrays can also be filled from the C side as well (look for PdBase copyArray*), but keep in mind this will also require sync'ing, so you may have to watch how large the arrays are if they are being filled while audio DSP is running. cheers, Rich On Sat, May 3, 2014 at 12:15 PM, Billy Stiltner billy.stilt...@gmail.comwrote: :) On Wed, Apr 30, 2014 at 5:57 AM, Miller Puckette m...@ucsd.edu wrote: Hi Matt - From Pd's perspective at least, it would be more efficient to handle the messages separately (some of Pd's list operations have to copy the list, which would be expensive if done iteratively over a long list). cheers Miller On Wed, Apr 30, 2014 at 01:37:05PM +0900, i go bananas wrote: I've got a six voice synth, each with about 20 variable parameters, and then sequence data, etc... and all of this data is being stored by the objective C front-end of my app. can someone tell me, hopefully from experience, what the best format is to send a lot of pattern data between obj C and libPD ??? should i package all the data as one huge list, or break it all into individual variables, or is it ok to organize it into groups for ease of management. my plan was to send messages like this from obj C: to [r instr1_pattern_data] : [vol 0.8, pan 0.5, pitch 0.75, param1 0.99 ... etc] actually, i'm not the one doing the C coding, i'm, just doing the pd side, but i have to prepare things on my end to make it flow as well as possible. Overall, i think there about 1400 values that need to be passed for every pattern, so it probably does need to be as well streamlined as possible. cheers for any help Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Installing PD on OpenSUSE
Hi All I've been trying to install pd-extended on OpenSUSE but whatever I do `make install` fails. It looks like it's trying to find pdlua_stack_dump but it's not defined... you can see the tail end of my make process here: https://gist.github.com/AJFaraday/2ee07be60ac7af5f7a6c If anyone knows why this isn't compiling I'd be grateful Regards Andrew Faraday P.S. If I can't figure this out I'm probably going to re-install this box with ubuntu again. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Installing PD on OpenSUSE
On 2014-05-11 12:45, Andrew Faraday wrote: Hi All I've been trying to install pd-extended on OpenSUSE but whatever I do `make install` fails. It looks like it's trying to find pdlua_stack_dump but it's not defined... The latest code should compile for Lua5.2 as well as 5.1, do you have this version of the pdlua makefile?: http://sourceforge.net/p/pure-data/svn/17235/ Martin you can see the tail end of my make process here: https://gist.github.com/AJFaraday/2ee07be60ac7af5f7a6c If anyone knows why this isn't compiling I'd be grateful Regards Andrew Faraday P.S. If I can't figure this out I'm probably going to re-install this box with ubuntu again. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Installing PD on OpenSUSE
I was under the impression that I had the latest code, I built it using Pd-extended_0.43.4-source.tar.bz2 line 152 is: LUACFLAGS += -I/usr/include/lua5.1 Also dependencies seem very sparsely documented, could I be missing one? Andrew F Date: Sun, 11 May 2014 13:13:09 -0400 From: martin.pe...@sympatico.ca To: jbtur...@hotmail.com; pd-list@iem.at Subject: Re: [PD] Installing PD on OpenSUSE On 2014-05-11 12:45, Andrew Faraday wrote: Hi All I've been trying to install pd-extended on OpenSUSE but whatever I do `make install` fails. It looks like it's trying to find pdlua_stack_dump but it's not defined... The latest code should compile for Lua5.2 as well as 5.1, do you have this version of the pdlua makefile?: http://sourceforge.net/p/pure-data/svn/17235/ Martin you can see the tail end of my make process here: https://gist.github.com/AJFaraday/2ee07be60ac7af5f7a6c If anyone knows why this isn't compiling I'd be grateful Regards Andrew Faraday P.S. If I can't figure this out I'm probably going to re-install this box with ubuntu again. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Installing PD on OpenSUSE
I removed the requirement for 5.1 in the makkefile, this was in January of this year. I don't know when the pd-extended externals source was last updated from svn, maybe it needs refreshing. From the diff: - LUACFLAGS += -I/usr/include/lua5.1 # lua is named differently on every platform, check this and change it to fit - LIBS += -llua5.1 # lua is named differently on every platform, check this and change it to fit + LUACFLAGS += -I/usr/include/lua # lua is named differently on every platform, check this and change it to fit + LIBS += -llua # lua is named differently on every platform, check this and change it to fit Also there are some changes in pdlua.c to accommodate the new API in lua5.2, as seen here: http://sourceforge.net/p/pure-data/svn/17235 Martin On 2014-05-11 13:26, Andrew Faraday wrote: I was under the impression that I had the latest code, I built it using Pd-extended_0.43.4-source.tar.bz2 line 152 is: LUACFLAGS += -I/usr/include/lua5.1 Also dependencies seem very sparsely documented, could I be missing one? Andrew F Date: Sun, 11 May 2014 13:13:09 -0400 From: martin.pe...@sympatico.ca To: jbtur...@hotmail.com; pd-list@iem.at Subject: Re: [PD] Installing PD on OpenSUSE On 2014-05-11 12:45, Andrew Faraday wrote: Hi All I've been trying to install pd-extended on OpenSUSE but whatever I do `make install` fails. It looks like it's trying to find pdlua_stack_dump but it's not defined... The latest code should compile for Lua5.2 as well as 5.1, do you have this version of the pdlua makefile?: http://sourceforge.net/p/pure-data/svn/17235/ Martin you can see the tail end of my make process here: https://gist.github.com/AJFaraday/2ee07be60ac7af5f7a6c If anyone knows why this isn't compiling I'd be grateful Regards Andrew Faraday P.S. If I can't figure this out I'm probably going to re-install this box with ubuntu again. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] From code poetry to interpretive PD poetry reading
Hi All, For a while now, I've been writing short perl scripts as works of art. Somehow, this practice of mine has become associated with poetry, which was never my intention at all. Here's a new direction I'm experimenting with, interpretive poetry reading via PD... (requires the ratts external: http://kaskade.dwds.de/~moocow/mirror/projects/pd/). Title: Becumming Cummings -- * Pall Thayer artist http://pallthayer.dyndns.org * cummings.tar.gz Description: GNU Zip compressed data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
thanks to all for your responses... very helpful! i've implemented a solution based on lorenzo's suggestion, and it works just fine! one further question: since my slider is in a gui panel for the patch, with all the other code buried in subpatches, is there a way to get the slider's send to float out of view (other than just sticking it under the slider!)? thanks again... cheers! .pltk. On 2014-05-09 07:22, Lorenzo Sutton wrote: On 09/05/2014 07:24, plutek infinity wrote: [...] i'm trying to control one numerical value in a few ways: 1. have a bang to set an initial value 2. have a slider for mouse control 3. use keyboard keys to increment and decrement [...] the problem is, of course, that if i connect the expr result back up to the slider input, i get a loop with stack overflow errors. See attached. This indeed uses the IEM gui'trick' where if you set all sends and receive to the same name in the properties they will be in sync. Please disregard my previous message about crashing.. (I was erroneously using a vanilla numberbox instead of the Number2 (IEM gui) one). Lorenzo. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 05? 10? 23:56, plutek infinity wrote: since my slider is in a gui panel for the patch, with all the other code buried in subpatches, is there a way to get the slider's send to float out of view (other than just sticking it under the slider!)? by turning it into an abstraction using Graph on parent (GOP) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNuSF0ACgkQ3EB7kzgMM6L0hQCfYt9tlzRSdPx+nFL4SAOOET2c NGEAn2zVA53Ndb3MKjjlooXMPnLF2Th5 =/J26 -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
thanks, max! right, so it looks like this needs to be the summer of pd tutorials! :) cheers! .pltk. On 2014-05-10 11:40, Max wrote: On 2014? 05? 10? 23:56, plutek infinity wrote: since my slider is in a gui panel for the patch, with all the other code buried in subpatches, is there a way to get the slider's send to float out of view (other than just sticking it under the slider!)? by turning it into an abstraction using Graph on parent (GOP) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
...which makes me wonder: besides all the various tutorials, is there a comprehensive online course about pd that one can work through? cheers! .pltk. On 2014-05-10 11:58, plutek infinity wrote: thanks, max! right, so it looks like this needs to be the summer of pd tutorials! :) cheers! .pltk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best format for send/receive between iOS and libPD
I'd second what Miller said, for a different reason though: every time you send a message from your app's main thread (the iOS / obj-c bits) into pd (the libpd bits), a mutex will lock because the audio thread runs on a different thread and needs to be synchronized. Breaking the lists down (not all the way down, just not one giant list) will mean that the synchronization takes less time, so less chance of dropping audio packets. Also, if you can, I'd store as much data as you can in pd arrays, and then send across lookup information instead. Pd arrays can also be filled from the C side as well (look for PdBase copyArray*), but keep in mind this will also require sync'ing, so you may have to watch how large the arrays are if they are being filled while audio DSP is running. cheers, Rich On Sat, May 3, 2014 at 12:15 PM, Billy Stiltner billy.stilt...@gmail.comwrote: :) On Wed, Apr 30, 2014 at 5:57 AM, Miller Puckette m...@ucsd.edu wrote: Hi Matt - From Pd's perspective at least, it would be more efficient to handle the messages separately (some of Pd's list operations have to copy the list, which would be expensive if done iteratively over a long list). cheers Miller On Wed, Apr 30, 2014 at 01:37:05PM +0900, i go bananas wrote: I've got a six voice synth, each with about 20 variable parameters, and then sequence data, etc... and all of this data is being stored by the objective C front-end of my app. can someone tell me, hopefully from experience, what the best format is to send a lot of pattern data between obj C and libPD ??? should i package all the data as one huge list, or break it all into individual variables, or is it ok to organize it into groups for ease of management. my plan was to send messages like this from obj C: to [r instr1_pattern_data] : [vol 0.8, pan 0.5, pitch 0.75, param1 0.99 ... etc] actually, i'm not the one doing the C coding, i'm, just doing the pd side, but i have to prepare things on my end to make it flow as well as possible. Overall, i think there about 1400 values that need to be passed for every pattern, so it probably does need to be as well streamlined as possible. cheers for any help Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
I took a stab at it. The main item here is the [set $1( message. That allows you to update the display/state of the slider without outputting a value. The [trigger a a] isn't needed for the patch to run correctly, but it makes it easier to see the connection that feeds back up the chain. -Jonathan On Friday, May 9, 2014 1:33 AM, plutek infinity plu...@infinity.net wrote: greetings! i'm sure this is a simple problem, but i can't seem to come up with the solution... i'm trying to control one numerical value in a few ways: 1. have a bang to set an initial value 2. have a slider for mouse control 3. use keyboard keys to increment and decrement the attached patch all works, except i ALSO want the slider position to pick up the current value, as changed by any of the other methods. the problem is, of course, that if i connect the expr result back up to the slider input, i get a loop with stack overflow errors. i'd be most grateful for any pointers you can offer... thanks much! cheers! .pltk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list multi-control_test_rev.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
Hi, you could use a set $1-message to only set the slider's display value without letting it propagate the new value to its outlet. Ciao -- Frank On Fri, May 09, 2014 at 01:24:34AM -0400, plutek infinity wrote: greetings! i'm sure this is a simple problem, but i can't seem to come up with the solution... i'm trying to control one numerical value in a few ways: 1. have a bang to set an initial value 2. have a slider for mouse control 3. use keyboard keys to increment and decrement the attached patch all works, except i ALSO want the slider position to pick up the current value, as changed by any of the other methods. the problem is, of course, that if i connect the expr result back up to the slider input, i get a loop with stack overflow errors. i'd be most grateful for any pointers you can offer... thanks much! cheers! .pltk. #N canvas 0 29 958 1049 10; #X obj 54 95 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 55 117 0.9; #X obj 251 122 key; #X obj 251 144 select 113; #X obj 125 330 expr $f1+$f2; #X msg 251 167 0.05; #X floatatom 125 352 5 0 0 0 - - -, f 5; #X obj 89 69 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 1000 1; #X obj 211 183 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 150 297 float; #X obj 369 116 key; #X obj 333 178 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 369 138 select 97; #X msg 369 161 -0.05; #X msg 184 134 0; #X connect 0 0 1 0; #X connect 0 0 14 0; #X connect 1 0 9 0; #X connect 2 0 3 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 4 0 9 1; #X connect 5 0 4 1; #X connect 5 0 8 0; #X connect 7 0 9 0; #X connect 7 0 14 0; #X connect 8 0 9 0; #X connect 9 0 4 0; #X connect 10 0 12 0; #X connect 11 0 9 0; #X connect 12 0 13 0; #X connect 13 0 11 0; #X connect 13 0 4 1; #X connect 14 0 4 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Frank Barknecht _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
Hi, On 09/05/2014 07:24, plutek infinity wrote: greetings! i'm sure this is a simple problem, but i can't seem to come up with the solution... i'm trying to control one numerical value in a few ways: 1. have a bang to set an initial value 2. have a slider for mouse control 3. use keyboard keys to increment and decrement the attached patch all works, except i ALSO want the slider position to pick up the current value, as changed by any of the other methods. Does the send / receive trick to sync e.g. a numberbox and a slider still work? It seems to crash Pd on windows. the problem is, of course, that if i connect the expr result back up to the slider input, i get a loop with stack overflow errors. i'd be most grateful for any pointers you can offer... thanks much! cheers! .pltk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
you can also use [change] in the chain to make sure messages are not resent when they are the same On Fri, May 9, 2014 at 6:12 PM, Lorenzo Sutton lorenzofsut...@gmail.comwrote: Hi, On 09/05/2014 07:24, plutek infinity wrote: greetings! i'm sure this is a simple problem, but i can't seem to come up with the solution... i'm trying to control one numerical value in a few ways: 1. have a bang to set an initial value 2. have a slider for mouse control 3. use keyboard keys to increment and decrement the attached patch all works, except i ALSO want the slider position to pick up the current value, as changed by any of the other methods. Does the send / receive trick to sync e.g. a numberbox and a slider still work? It seems to crash Pd on windows. the problem is, of course, that if i connect the expr result back up to the slider input, i get a loop with stack overflow errors. i'd be most grateful for any pointers you can offer... thanks much! cheers! .pltk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] recursive controls problem
On 09/05/2014 07:24, plutek infinity wrote: [...] i'm trying to control one numerical value in a few ways: 1. have a bang to set an initial value 2. have a slider for mouse control 3. use keyboard keys to increment and decrement [...] the problem is, of course, that if i connect the expr result back up to the slider input, i get a loop with stack overflow errors. See attached. This indeed uses the IEM gui'trick' where if you set all sends and receive to the same name in the properties they will be in sync. Please disregard my previous message about crashing.. (I was erroneously using a vanilla numberbox instead of the Number2 (IEM gui) one). Lorenzo. #N canvas 275 188 871 498 10; #X obj 35 29 hsl 128 20 -10 10 0 0 aa aa empty -2 -8 0 10 -1 -4034 -4034 11366 1; #X obj 191 36 nbx 5 14 -10 10 0 0 aa aa empty 0 -8 0 14 -1 -4032 -4032 7.9 256; #X obj 240 408 + 0.05; #X obj 43 410 float 0.9; #X obj 43 144 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 43 164 0.9; #X obj 60 196 s aa; #X obj 32 63 s to_float; #X obj 103 196 r to_float; #X obj 344 66 key; #X obj 344 100 sel 113 97; #X floatatom 388 84 5 0 0 0 - - -, f 5; #X msg 344 128 1; #X msg 377 128 -1; #X obj 372 238 *; #X obj 336 188 f 0.05; #X floatatom 413 268 5 0 0 0 - - -, f 5; #X obj 390 188 change; #X obj 347 267 t b b f; #X obj 344 159 t b b f; #X text 6 5 open properties to see send/recieve trick...; #X text 19 86 needed to explicitly set the value \; when mous is used ; #X obj 43 464 s aa; #X obj 44 432 clip -10 10; #X text 136 436 In case you want this range (see also GUI objects' properits...); #X text 313 338 - this bang (going into the [+ 0.05]) is needed for correct change of 'direction' (try without...); #X connect 0 0 7 0; #X connect 1 0 7 0; #X connect 2 0 3 1; #X connect 3 0 23 0; #X connect 4 0 5 0; #X connect 5 0 6 0; #X connect 5 0 3 0; #X connect 8 0 3 0; #X connect 9 0 10 0; #X connect 9 0 11 0; #X connect 10 0 12 0; #X connect 10 1 13 0; #X connect 12 0 19 0; #X connect 13 0 19 0; #X connect 14 0 16 0; #X connect 14 0 18 0; #X connect 15 0 14 0; #X connect 17 0 14 1; #X connect 18 0 3 0; #X connect 18 1 2 0; #X connect 18 2 2 1; #X connect 19 1 15 0; #X connect 19 2 17 0; #X connect 23 0 22 0; #X connect 23 0 2 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] convolution using pd-vanilla
and it took me quite some time to figure it out :) 2014-05-06 10:55 GMT-03:00 Oli Larkin olilar...@googlemail.com: thanks everyone ... Alexandre that is just what i was looking for On 6 May 2014, at 06:09, Alexandre Torres Porres wrote: I did one and shared on the list you can check it at: https://drive.google.com/file/d/0B3AoiT0xk8fnNU9PRHdldVVFbU0/edit?usp=sharing 2014-05-05 16:41 GMT-03:00 katja katjavet...@gmail.com: Brute force time domain convolution for small kernel can be done with [fexpr~]. For zero phase filter kernels, fast convolution in Pd is relatively simple. Multiply real and imaginary part of the signal's spectrum with the filter's spectrum while using four times overlap and Hann windowing before FFT and after IFFT, and normalize. Pd's FFT routines assume x[0] at the start of the filter kernel, not at the center, so you have to rotate your zero phase filter kernel before taking it's Fourier Transform. Katja On Mon, May 5, 2014 at 8:49 PM, david medine dmed...@ucsd.edu wrote: For the FFT based convolution, you could easily modify the example patch I06.timbre.stamp.pd to do straight up convolution in the frequency domain. I wouldn't know how to do it in the time domain without an extern or a lot of painstaking work. It might be a nice thing to have, though. I can tell you, though, that the frequency domain method will out perform the time domain in terms of CPU usage. But, since you are windowing there will be a latency. Apart from that, the output is identical by both methods. y(n) = x(n) * g(n) Y(k) = X(k)G(k), y(n) = IDFT(Y(k)) where g(n) is the impulse response, X(k) is the discrete Fourier transform of x(n) and * is the convolution operation. On 05/05/2014 09:33 AM, Oli Larkin wrote: hi, is anyone aware of an example of both a brute force time domain (e.g. buffir~ in Max) and an FFT-based fast convolution patch in pd-vanilla? I would like to do a comparison of the two. Can be using a small IR, just for demo purposes. cheers, Oli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] more sprites!
Hi list, Here's another data structure sprite example: http://www.jonathanwilkes.net/sprite.webm I changed the object name and interface a little bit-- now sprites can have affine transformations. It's neat to use the transform method to see how few objects it takes to animate the sprite across the screen. Under the hood, the transform method should also be more efficient-- instead of vis'ing and unvis'ing the scalar, it just sends updated attribute to the image. Does anyone know if there's a standard sprite sheet format? Some sprite sheets divide up the sections into perfectly equal parts-- others look like they just spread them out arbitrarily through a png or gif. Atm I just take a directory as an arg and slurp up an image sequence. (And use imagemagick to split up the sprite sheet.) Best, Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] recursive controls problem
greetings! i'm sure this is a simple problem, but i can't seem to come up with the solution... i'm trying to control one numerical value in a few ways: 1. have a bang to set an initial value 2. have a slider for mouse control 3. use keyboard keys to increment and decrement the attached patch all works, except i ALSO want the slider position to pick up the current value, as changed by any of the other methods. the problem is, of course, that if i connect the expr result back up to the slider input, i get a loop with stack overflow errors. i'd be most grateful for any pointers you can offer... thanks much! cheers! .pltk. #N canvas 0 29 958 1049 10; #X obj 54 95 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 55 117 0.9; #X obj 251 122 key; #X obj 251 144 select 113; #X obj 125 330 expr $f1+$f2; #X msg 251 167 0.05; #X floatatom 125 352 5 0 0 0 - - -, f 5; #X obj 89 69 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 1000 1; #X obj 211 183 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 150 297 float; #X obj 369 116 key; #X obj 333 178 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 369 138 select 97; #X msg 369 161 -0.05; #X msg 184 134 0; #X connect 0 0 1 0; #X connect 0 0 14 0; #X connect 1 0 9 0; #X connect 2 0 3 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 4 0 9 1; #X connect 5 0 4 1; #X connect 5 0 8 0; #X connect 7 0 9 0; #X connect 7 0 14 0; #X connect 8 0 9 0; #X connect 9 0 4 0; #X connect 10 0 12 0; #X connect 11 0 9 0; #X connect 12 0 13 0; #X connect 13 0 11 0; #X connect 13 0 4 1; #X connect 14 0 4 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] convolution using pd-vanilla
thanks everyone ... Alexandre that is just what i was looking for On 6 May 2014, at 06:09, Alexandre Torres Porres wrote: I did one and shared on the list you can check it at:https://drive.google.com/file/d/0B3AoiT0xk8fnNU9PRHdldVVFbU0/edit?usp=sharing 2014-05-05 16:41 GMT-03:00 katja katjavet...@gmail.com: Brute force time domain convolution for small kernel can be done with [fexpr~]. For zero phase filter kernels, fast convolution in Pd is relatively simple. Multiply real and imaginary part of the signal's spectrum with the filter's spectrum while using four times overlap and Hann windowing before FFT and after IFFT, and normalize. Pd's FFT routines assume x[0] at the start of the filter kernel, not at the center, so you have to rotate your zero phase filter kernel before taking it's Fourier Transform. Katja On Mon, May 5, 2014 at 8:49 PM, david medine dmed...@ucsd.edu wrote: For the FFT based convolution, you could easily modify the example patch I06.timbre.stamp.pd to do straight up convolution in the frequency domain. I wouldn't know how to do it in the time domain without an extern or a lot of painstaking work. It might be a nice thing to have, though. I can tell you, though, that the frequency domain method will out perform the time domain in terms of CPU usage. But, since you are windowing there will be a latency. Apart from that, the output is identical by both methods. y(n) = x(n) * g(n) Y(k) = X(k)G(k), y(n) = IDFT(Y(k)) where g(n) is the impulse response, X(k) is the discrete Fourier transform of x(n) and * is the convolution operation. On 05/05/2014 09:33 AM, Oli Larkin wrote: hi, is anyone aware of an example of both a brute force time domain (e.g. buffir~ in Max) and an FFT-based fast convolution patch in pd-vanilla? I would like to do a comparison of the two. Can be using a small IR, just for demo purposes. cheers, Oli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] convolution using pd-vanilla
hi, is anyone aware of an example of both a brute force time domain (e.g. buffir~ in Max) and an FFT-based fast convolution patch in pd-vanilla? I would like to do a comparison of the two. Can be using a small IR, just for demo purposes. cheers, Oli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] convolution using pd-vanilla
For the FFT based convolution, you could easily modify the example patch I06.timbre.stamp.pd to do straight up convolution in the frequency domain. I wouldn't know how to do it in the time domain without an extern or a lot of painstaking work. It might be a nice thing to have, though. I can tell you, though, that the frequency domain method will out perform the time domain in terms of CPU usage. But, since you are windowing there will be a latency. Apart from that, the output is identical by both methods. y(n) = x(n) * g(n) Y(k) = X(k)G(k), y(n) = IDFT(Y(k)) where g(n) is the impulse response, X(k) is the discrete Fourier transform of x(n) and * is the convolution operation. On 05/05/2014 09:33 AM, Oli Larkin wrote: hi, is anyone aware of an example of both a brute force time domain (e.g. buffir~ in Max) and an FFT-based fast convolution patch in pd-vanilla? I would like to do a comparison of the two. Can be using a small IR, just for demo purposes. cheers, Oli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] convolution using pd-vanilla
Brute force time domain convolution for small kernel can be done with [fexpr~]. For zero phase filter kernels, fast convolution in Pd is relatively simple. Multiply real and imaginary part of the signal's spectrum with the filter's spectrum while using four times overlap and Hann windowing before FFT and after IFFT, and normalize. Pd's FFT routines assume x[0] at the start of the filter kernel, not at the center, so you have to rotate your zero phase filter kernel before taking it's Fourier Transform. Katja On Mon, May 5, 2014 at 8:49 PM, david medine dmed...@ucsd.edu wrote: For the FFT based convolution, you could easily modify the example patch I06.timbre.stamp.pd to do straight up convolution in the frequency domain. I wouldn't know how to do it in the time domain without an extern or a lot of painstaking work. It might be a nice thing to have, though. I can tell you, though, that the frequency domain method will out perform the time domain in terms of CPU usage. But, since you are windowing there will be a latency. Apart from that, the output is identical by both methods. y(n) = x(n) * g(n) Y(k) = X(k)G(k), y(n) = IDFT(Y(k)) where g(n) is the impulse response, X(k) is the discrete Fourier transform of x(n) and * is the convolution operation. On 05/05/2014 09:33 AM, Oli Larkin wrote: hi, is anyone aware of an example of both a brute force time domain (e.g. buffir~ in Max) and an FFT-based fast convolution patch in pd-vanilla? I would like to do a comparison of the two. Can be using a small IR, just for demo purposes. cheers, Oli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] analog PD+GEM
Jeenyoos! BTW I went to a modular synth meetup the other day. Hoxtonowl were demoing a eurorack module that runs Pd. They already have an effects pedal that uses it: http://hoxtonowl.com/2014/04/owl-puredata-alphatesters-wanted/ Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ On Thursday, 17 April 2014, 18:12, Chris Clepper cgclep...@gmail.com wrote: I played a bit with it at last year's AHNE meet. It was perplexing to use even for someone with extensive video and Eurorack experience! I think it is still just the one-off module. Crazy device though.. On Thu, Apr 17, 2014 at 12:09 PM, Dan Wilcox danomat...@gmail.com wrote: Hehe https://www.youtube.com/watch?v=63ay74S34XI Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] convolution using pd-vanilla
I did one and shared on the list you can check it at: https://drive.google.com/file/d/0B3AoiT0xk8fnNU9PRHdldVVFbU0/edit?usp=sharing 2014-05-05 16:41 GMT-03:00 katja katjavet...@gmail.com: Brute force time domain convolution for small kernel can be done with [fexpr~]. For zero phase filter kernels, fast convolution in Pd is relatively simple. Multiply real and imaginary part of the signal's spectrum with the filter's spectrum while using four times overlap and Hann windowing before FFT and after IFFT, and normalize. Pd's FFT routines assume x[0] at the start of the filter kernel, not at the center, so you have to rotate your zero phase filter kernel before taking it's Fourier Transform. Katja On Mon, May 5, 2014 at 8:49 PM, david medine dmed...@ucsd.edu wrote: For the FFT based convolution, you could easily modify the example patch I06.timbre.stamp.pd to do straight up convolution in the frequency domain. I wouldn't know how to do it in the time domain without an extern or a lot of painstaking work. It might be a nice thing to have, though. I can tell you, though, that the frequency domain method will out perform the time domain in terms of CPU usage. But, since you are windowing there will be a latency. Apart from that, the output is identical by both methods. y(n) = x(n) * g(n) Y(k) = X(k)G(k), y(n) = IDFT(Y(k)) where g(n) is the impulse response, X(k) is the discrete Fourier transform of x(n) and * is the convolution operation. On 05/05/2014 09:33 AM, Oli Larkin wrote: hi, is anyone aware of an example of both a brute force time domain (e.g. buffir~ in Max) and an FFT-based fast convolution patch in pd-vanilla? I would like to do a comparison of the two. Can be using a small IR, just for demo purposes. cheers, Oli ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] comparing symbols in external
Hi all,
I am trying to compare two symbols, one incoming in a list into an external and
the other one stored internally in the external.
It compiles fine, but I don't get a match.
c code is below. Ideas on what I'm missing?
J
void testtext_input(t_testtext *x, t_symbol *selector, int argcount, t_atom
*argvec) {
int i;
const t_symbol *storedsymbol = gensym(mysymbol);
for (i = 0; i argcount; i++) {
if (argvec[i].a_type == A_SYMBOL) {
if ( argvec[i].a_w.w_symbol-s_name == storedsymbol)
post(found match!);
}
}
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] comparing symbols in external
Strange things like this can happen if someone inadvertently writes
a new string into an existing symbol... i.e., never do this:
strcat(sym-s_name, cat).
MAybe there was already a symbol somewhere else whose name is cat and
then you'll have 2 symbols with teh same name but different addresses.
(I've seen people do this, in various ways, before).
cheers
Miller
On Sat, May 03, 2014 at 03:22:19AM -0400, Jaime E Oliver wrote:
Hi all,
I am trying to compare two symbols, one incoming in a list into an external
and the other one stored internally in the external.
It compiles fine, but I don't get a match.
c code is below. Ideas on what I'm missing?
J
void testtext_input(t_testtext *x, t_symbol *selector, int argcount, t_atom
*argvec) {
int i;
const t_symbol *storedsymbol = gensym(mysymbol);
for (i = 0; i argcount; i++) {
if (argvec[i].a_type == A_SYMBOL) {
if ( argvec[i].a_w.w_symbol-s_name == storedsymbol)
post(found match!);
}
}
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] comparing symbols in external
On 05/03/2014 09:22 AM, Jaime E Oliver wrote:
Hi all,
I am trying to compare two symbols, one incoming in a list into an external
and the other one stored internally in the external.
It compiles fine, but I don't get a match.
c code is below. Ideas on what I'm missing
the whole idea about symbols is, that you can do a pointer comparision
of the *symbol*.
so it should be as simple as:
if(argvec[i].a_type == A_SYMBOL argvec[i].a_w.w_symbol ==
storedsymbol) post(found match);
if (argvec[i].a_type == A_SYMBOL) {
if ( argvec[i].a_w.w_symbol-s_name == storedsymbol)
post(found match!);
the -s_name field of the symbol is the pointer to the actual C-string,
whereas storedsymbol is a pointer to the symbol.
so you are doing a compare ((const char*)cstr == (t_symbol*)sym), which
is clearly wrong.
fgmsadr
IOhannes
signature.asc
Description: OpenPGP digital signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] comparing symbols in external
Thanks to both, it makes sense and it works now.
J
On May 3, 2014, at 4:42 AM, IOhannes m zmölnig zmoel...@iem.at wrote:
On 05/03/2014 09:22 AM, Jaime E Oliver wrote:
Hi all,
I am trying to compare two symbols, one incoming in a list into an external
and the other one stored internally in the external.
It compiles fine, but I don't get a match.
c code is below. Ideas on what I'm missing
the whole idea about symbols is, that you can do a pointer comparision
of the *symbol*.
so it should be as simple as:
if(argvec[i].a_type == A_SYMBOL argvec[i].a_w.w_symbol ==
storedsymbol) post(found match);
if (argvec[i].a_type == A_SYMBOL) {
if ( argvec[i].a_w.w_symbol-s_name == storedsymbol)
post(found match!);
the -s_name field of the symbol is the pointer to the actual C-string,
whereas storedsymbol is a pointer to the symbol.
so you are doing a compare ((const char*)cstr == (t_symbol*)sym), which
is clearly wrong.
fgmsadr
IOhannes
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] best format for send/receive between iOS and libPD
:) On Wed, Apr 30, 2014 at 5:57 AM, Miller Puckette m...@ucsd.edu wrote: Hi Matt - From Pd's perspective at least, it would be more efficient to handle the messages separately (some of Pd's list operations have to copy the list, which would be expensive if done iteratively over a long list). cheers Miller On Wed, Apr 30, 2014 at 01:37:05PM +0900, i go bananas wrote: I've got a six voice synth, each with about 20 variable parameters, and then sequence data, etc... and all of this data is being stored by the objective C front-end of my app. can someone tell me, hopefully from experience, what the best format is to send a lot of pattern data between obj C and libPD ??? should i package all the data as one huge list, or break it all into individual variables, or is it ok to organize it into groups for ease of management. my plan was to send messages like this from obj C: to [r instr1_pattern_data] : [vol 0.8, pan 0.5, pitch 0.75, param1 0.99 ... etc] actually, i'm not the one doing the C coding, i'm, just doing the pd side, but i have to prepare things on my end to make it flow as well as possible. Overall, i think there about 1400 values that need to be passed for every pattern, so it probably does need to be as well streamlined as possible. cheers for any help Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MobMuPlat - data from several iPads to one PC
Thanks Dan! It worked so far with the help patch! Now I have just to see how it’s going with several iPads… Thanks again! chris Am 03.05.2014 um 01:30 schrieb Daniel Iglesia daniel.igle...@gmail.com: (And for multiple devices into a pd patch, I usually have the user of each device manually input a number identifying their identity, and then filter/route based on this in the PC patch) (If you choose to use LANdini, you'll want to get the standalone client (OSX only, or supercollider code) for the hub computer) Sent from my iPhone On May 2, 2014, at 4:49 PM, Christian Fischer m...@c-m-fischer.de wrote: Hi there, not sure whether I can make out the forest for the trees after x hours of fiddling… What would be the best way to send data (one way) from several iPads to one master patch on PC, connected adhoc wireless? So far I tried only with one iPad, used MobMuPlat and simple ‚netsend' / ‚netreceive'. For one iPad it worked pretty fine! Now I wonder what about several iPads. Can’t test before Monday, but I would like to prepare everything before… The idea is several people use the iPads as interfaces to manipulate a master patch on a PC connected to interface, several speakers etc… They do not have to get any feedback from master patch. Data flows only one way. MobMuPlat does not take ‚packOSC‘. Would ‚LANdini‘ be better for several iPads (could not get it running so far. still trying…) Or is there something else? Any experiences? Thanx Best! chris ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] puredata.info down
Just wanted to report the site is down. Been that way for at least a few hours judging by the forum. -- Richie www.glitchpop.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to get a list of midi devices without GUI
On Sun, Feb 9, 2014 at 5:20 PM, Jonathan Wilkes jancs...@yahoo.com wrote: In Pd-l2ork you can also do this: [print( | [pdinfo] Which prints all the info for the running Pd instance to the console, including devices. Or you can send it a message to get a specific attribute like [audio-outdev, midi-outdevlist( | [pdinfo] I tried it with [loadbang] and -nogui, and all the audio devices display properly. I can't test midi because I don't have any midi devices. -Jonathan audio-outdev, midi-outdevlist gives me nothing but a bang. I have ALSA midi-outs connected. Might this be a bug? András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to get a list of midi devices without GUI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-02-09 16:45, Antoine Villeret wrote: Shouldn't `[mediasettings/midisettings]` update it's own device lists on `[listdevices(` message ? please file a feature-request (and assign it to me, if possible) fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTY1OsAAoJELZQGcR/ejb4mnQP/2LNqaPkJxA0AuRG/d1PN1d9 RmZMsIhtrhyWr1HEO0n5ZcapkcD1lYEGw/kbHJ+A5i29Wp2zSqqKiDdvJ1Af9M6V 8mhu56W/14K/gN1Yn2wBjhU/CgWkwI8mZzwY3xKKMbSvlbj3qwyzXz/tnqd+5tym 7Ej34M2PhEaazelAwOjgjI+ERC1U5u+9HkhR9mfoBWgkoSa2LG82ZB5PO+/DZ9F1 8HPwy/FVq2KblhyfbLi6B0JV0MhujF4IY9DhLnn8GxNDbefvG/zmXcsxhqju3ZEs VMDFXCpTY8aoXve+t/mNl1mXmpRD6zAtJhfIm5ljRuu4v7GjGJBJs8PfPWxRceIc Bp49S+HZHDg6oojZTA+vW77iz3xpg1A/qIuSmKbdX55Zxk6obQ7KDhHLxObmqieg 3gkIscjMluZMFRobN9crw5qFnHlVauio5cWvFnciuU8RUXLQ8HzfvOdMwV3GBczp lK6tZmNWADto9cvi82rjdILPA48DwZXHy1QoLeTaP3+N1vN04Vnd9lE64yvMo+mA sSbgLkudhOT7NK8U4Ut5jWwAwt3WX+hUxfPaJ3shJ44wpRekz8zYko7nz5eghar5 bfq2PP2Nro3z2NVrgSHc8Uyx5em4loPnQUSVjgFXz/izwld27FXZds6P23Ek0iPU JwSkFLt0VLD4QDBxLFT3 =bXEL -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] gridflow pd-extended ubuntu 14.04
hello, i have dedicated some time to updating my system, ending up with ubuntu 14.04 doing the occasional patching now. everything pd related went relatively painless, just had to rebuild Gem, but gridflow's stuck and won't move a bit and i have no clue. i have gridflow in it's own builddir: /home/ub/build/gridflow here i do update per svn, then configure and make, but when loading in pd i consistently get: home/ub/build/gridflow/gridflow.pd_linux: /home/ub/build/gridflow/gridflow.pd_linux: undefined symbol: cvEllipse gridflow: can't load library /home/ub/build/gridflow/gridflow_gem9393.pd_linux: /home/ub/build/gridflow/gridflow_gem9393.pd_linux: undefined symbol: _ZTI7FObject gridflow_gem9393: can't load library system is amd64, pd: 0.43-3, GEM: 0.93.3, gridflow says it's At revision 6881 ideas anyone? thanks+ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] puredata.info down
On 05/02/2014 07:03 AM, Richie Cyngler wrote: Just wanted to report the site is down. Been that way for at least a few hours judging by the forum. there was a power-outage that drained our UPS and blew the fuses. all should be up and running again. gfmsard IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] Muditulib: first test release
Hello all, For those who would like to try my new tuning library before it is released: the first test release of Muditulib is now available on sourceforge. Algorithms to translate less into more dimensions are not included yet. However, the tuning and pitch systems should be working. A reference manual is also not available yet, but relevant information can be extracted from the articles on my website, LAC2014 proceedings, and slides on the LAC2014 website, as well as from the Pd help files. https://sourceforge.net/projects/muditulib/ http://muditulib.eu/ http://lac.linuxaudio.org/2014/files Muditulib, a multi-dimensional tuning library, is a library to be implemented (wholly or partly) in music production software. It consists of a core of C functions. Additionally a Pure Data implementation is provided. This implementation consist of several classes to be used as a modular system. The library makes use of a multi-dimensional numerical pitch representation system, a variant of the very well-known one-dimensional MIDI note system. Ambitions for other implementations are very welcome. Muditulib offers new ways of approaching tuning within the scope of diatonic (roughly the majority of) tonal music within the digital domain. For more information please have a look at http://muditulib.eu, read the README.txt or the Muditulib Reference Manual. Kind regards, Funs Seelen ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gridflow pd-extended ubuntu 14.04
Le 02/05/2014 15:19, u...@xdv.org a écrit : hello, i have dedicated some time to updating my system, ending up with ubuntu 14.04 doing the occasional patching now. everything pd related went relatively painless, just had to rebuild Gem, but gridflow's stuck and won't move a bit and i have no clue. i have gridflow in it's own builddir: /home/ub/build/gridflow here i do update per svn, then configure and make, but when loading in pd i consistently get: home/ub/build/gridflow/gridflow.pd_linux: /home/ub/build/gridflow/gridflow.pd_linux: undefined symbol: cvEllipse gridflow: can't load library /home/ub/build/gridflow/gridflow_gem9393.pd_linux: /home/ub/build/gridflow/gridflow_gem9393.pd_linux: undefined symbol: _ZTI7FObject gridflow_gem9393: can't load library system is amd64, pd: 0.43-3, GEM: 0.93.3, gridflow says it's At revision 6881 ideas anyone? thanks+ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list hello, it seems that gem libraries aren't linked correctly by the build system, gridflow might run if Gem libs are disabled in configure, what about posting build logs? patko ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] A list of live electroacoustic ensembles
Hello all, If you're in a live electronics ensemble or know of such an ensemble that is not on this list http://bit.ly/1pyfyVJ, it'd be super nice if you could add it here (in the additions tab). The list includes electroacoustic ensembles and mixed ensembles that have a substantial live, communal (3 performers minimum) electroacoustic component (laptop, tablet, analog synth, DIY, etc.) Many thanks Eldad -- Dr. Eldad Tsabary, Assistant Professor Electroacoustic Studies, Music Department Director, Concordia Laptop Orchestra Concordia University, Montreal President, Communauté électroacoustique canadienne / Canadian Electroacoustic Community eldad.tsab...@concordia.ca 514-848-2424 #5163 (office) 514-884-8902 (cell)___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gridflow pd-extended ubuntu 14.04
On 02.05.2014 16:21, Colet Patrice wrote: Le 02/05/2014 15:19, u...@xdv.org a écrit : hello, i have dedicated some time to updating my system, ending up with ubuntu 14.04 doing the occasional patching now. everything pd related went relatively painless, just had to rebuild Gem, but gridflow's stuck and won't move a bit and i have no clue. i have gridflow in it's own builddir: /home/ub/build/gridflow here i do update per svn, then configure and make, but when loading in pd i consistently get: home/ub/build/gridflow/gridflow.pd_linux: /home/ub/build/gridflow/gridflow.pd_linux: undefined symbol: cvEllipse gridflow: can't load library /home/ub/build/gridflow/gridflow_gem9393.pd_linux: /home/ub/build/gridflow/gridflow_gem9393.pd_linux: undefined symbol: _ZTI7FObject gridflow_gem9393: can't load library system is amd64, pd: 0.43-3, GEM: 0.93.3, gridflow says it's At revision 6881 ideas anyone? thanks+ciao, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list hello, it seems that gem libraries aren't linked correctly by the build system, gridflow might run if Gem libs are disabled in configure, what about posting build logs? patko thanks for the quick reply. i tried ./configure --no-opengl upon make distclean but that lead to the same result for gridflow.pd_linux: undefined symbol: cvEllipse as this seems an openCv object, which is included directly by gridflow (not via Gem) from src/opencv.cxx i checked the config.log for opencv and really there was a line saying: Package opencv was not found in the pkg-config search path installing libopencv-dev fixed that and it's all good now :) thanks+cheers, ub ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Patching Circle] Generative Musical Apps this Friday!
Awesome! what time? 6:30pm? On Sun, Apr 27, 2014 at 9:29 PM, sonia yuditskaya marysgh...@gmail.comwrote: Hi Epic, the next patching circle will be on May 22 at ITP/NYU, 721 Broadway, 4th floor. Cheers! Sofy Yuditskaya s~ http://yuditskaya.com On Sat, Apr 26, 2014 at 2:50 PM, Epic Jefferson jeffreyconcepc...@gmail.com wrote: Hey Sofy, I'll be in NY from May 19-27. When is the patching circle? On Tue, Apr 8, 2014 at 2:36 PM, sonia yuditskaya marysgh...@gmail.comwrote: *Patching Circle* *Fri, April 116:30pm* *Conference Room* Embedded Generative Music Systems on Android and iOS with Chris McCormick and Dan Wilcox. Learn how to embed Pure Data on your Android or iPhone. The New York City Patching Circle is an free alternating monthly meeting and salon open to anyone who is working or interested in media programming and audiovisual performance. We mostly use Pd and Max/MSP, but all are welcome. Beginners and Experienced welcome. Open to everyone, students, the public, unicorns. Work on personal projects, professional projects, school projects, ask for help, help others, or just patch quietly to yourself in a room full of other people patching patches and helping other people patch. Each month there will be informal salon, featuring demonstrations of projects, performances and systems in the process of being built. The format will include short performances, artist talks about process and performance techniques and QA depending on time availability. The salon is openly curated with the intent of being as inclusive as possible and participation is open all practitioners working in realtime media. Sofy Yuditskaya s~ http://yuditskaya.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.epicjefferson.com -- www.epicjefferson.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] MobMuPlat - data from several iPads to one PC
Hi there, not sure whether I can make out the forest for the trees after x hours of fiddling… What would be the best way to send data (one way) from several iPads to one master patch on PC, connected adhoc wireless? So far I tried only with one iPad, used MobMuPlat and simple ‚netsend' / ‚netreceive'. For one iPad it worked pretty fine! Now I wonder what about several iPads. Can’t test before Monday, but I would like to prepare everything before… The idea is several people use the iPads as interfaces to manipulate a master patch on a PC connected to interface, several speakers etc… They do not have to get any feedback from master patch. Data flows only one way. MobMuPlat does not take ‚packOSC‘. Would ‚LANdini‘ be better for several iPads (could not get it running so far. still trying…) Or is there something else? Any experiences? Thanx Best! chris ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MobMuPlat - data from several iPads to one PC
Hi Mobmuplat handles networking at the app layer, not the pd patch layer. Take a look at the tutorial patch MMPTutorial4-Networking.pd which has both LANdini and non-LANdini (UDP multicast) examples of sending/receiving. In all cases, OSC messages come from/go to [receive fromNetwork] and [send toNetwork] objects, not netsend/receive. If you have further issues feel free to email me off-list. Dan Sent from my iPhone On May 2, 2014, at 4:49 PM, Christian Fischer m...@c-m-fischer.de wrote: Hi there, not sure whether I can make out the forest for the trees after x hours of fiddling… What would be the best way to send data (one way) from several iPads to one master patch on PC, connected adhoc wireless? So far I tried only with one iPad, used MobMuPlat and simple ‚netsend' / ‚netreceive'. For one iPad it worked pretty fine! Now I wonder what about several iPads. Can’t test before Monday, but I would like to prepare everything before… The idea is several people use the iPads as interfaces to manipulate a master patch on a PC connected to interface, several speakers etc… They do not have to get any feedback from master patch. Data flows only one way. MobMuPlat does not take ‚packOSC‘. Would ‚LANdini‘ be better for several iPads (could not get it running so far. still trying…) Or is there something else? Any experiences? Thanx Best! chris ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MobMuPlat - data from several iPads to one PC
(And for multiple devices into a pd patch, I usually have the user of each device manually input a number identifying their identity, and then filter/route based on this in the PC patch) (If you choose to use LANdini, you'll want to get the standalone client (OSX only, or supercollider code) for the hub computer) Sent from my iPhone On May 2, 2014, at 4:49 PM, Christian Fischer m...@c-m-fischer.de wrote: Hi there, not sure whether I can make out the forest for the trees after x hours of fiddling… What would be the best way to send data (one way) from several iPads to one master patch on PC, connected adhoc wireless? So far I tried only with one iPad, used MobMuPlat and simple ‚netsend' / ‚netreceive'. For one iPad it worked pretty fine! Now I wonder what about several iPads. Can’t test before Monday, but I would like to prepare everything before… The idea is several people use the iPads as interfaces to manipulate a master patch on a PC connected to interface, several speakers etc… They do not have to get any feedback from master patch. Data flows only one way. MobMuPlat does not take ‚packOSC‘. Would ‚LANdini‘ be better for several iPads (could not get it running so far. still trying…) Or is there something else? Any experiences? Thanx Best! chris ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] read from same array with multiple [tabread4~]'s
Yes, it's a problem with my patch! Thanks Quoth Miller Puckette, on 30/04/2014 15:31: There aren't any interactions between tabread4~ (etc.) objects reading from the same table - I do it all the time - for example, the silly example in 3.audio.examples/D13.addtive.qlst.pd cheers Miller On Wed, Apr 30, 2014 at 02:06:46PM +0100, James Dunn wrote: Hi, I'm trying to playback a sound file from the same array using multiple [tabread4~] objects but I'm getting nasty clicks presumably because they are having accessing the same array at the same time. Is there another approach to this or some other way of avoiding the clicks? thanks James ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] best format for send/receive between iOS and libPD
Hi Matt - From Pd's perspective at least, it would be more efficient to handle the messages separately (some of Pd's list operations have to copy the list, which would be expensive if done iteratively over a long list). cheers Miller On Wed, Apr 30, 2014 at 01:37:05PM +0900, i go bananas wrote: I've got a six voice synth, each with about 20 variable parameters, and then sequence data, etc... and all of this data is being stored by the objective C front-end of my app. can someone tell me, hopefully from experience, what the best format is to send a lot of pattern data between obj C and libPD ??? should i package all the data as one huge list, or break it all into individual variables, or is it ok to organize it into groups for ease of management. my plan was to send messages like this from obj C: to [r instr1_pattern_data] : [vol 0.8, pan 0.5, pitch 0.75, param1 0.99 ... etc] actually, i'm not the one doing the C coding, i'm, just doing the pd side, but i have to prepare things on my end to make it flow as well as possible. Overall, i think there about 1400 values that need to be passed for every pattern, so it probably does need to be as well streamlined as possible. cheers for any help Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] read from same array with multiple [tabread4~]'s
Hi, I'm trying to playback a sound file from the same array using multiple [tabread4~] objects but I'm getting nasty clicks presumably because they are having accessing the same array at the same time. Is there another approach to this or some other way of avoiding the clicks? thanks James ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] read from same array with multiple [tabread4~]'s
There aren't any interactions between tabread4~ (etc.) objects reading from the same table - I do it all the time - for example, the silly example in 3.audio.examples/D13.addtive.qlst.pd cheers Miller On Wed, Apr 30, 2014 at 02:06:46PM +0100, James Dunn wrote: Hi, I'm trying to playback a sound file from the same array using multiple [tabread4~] objects but I'm getting nasty clicks presumably because they are having accessing the same array at the same time. Is there another approach to this or some other way of avoiding the clicks? thanks James ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Hi Simon, Maybe it's just me but I did not find an attachment with your last post. By the way I found a bug in my upsampling method: apparently, [samplerate~] in a resampled subpatch needs some time before it reports the correct samplerate, therefore the subpatch used wrong values for filter frequency occasionally, which causes nonsense output. Attached is a fixed version. In the meantime I was wondering if upsampling is needed at all for accuracy. As Miller mentioned earlier, the error from truncating to integer nr of samples can be substantial. Attached patch 'errorsample' calculates that error and as you would expect, the error (expressed in cents) increases with frequency. However, in our patches I can't hear the error! Even if the unsig'ed frequency value shows fluctuation, the sound is stable. For comparison, you could control [phasor~] with the unsig'ed value, then you'll hear what the error really sounds like. So why don't we hear that when [phasor~] is controlled by the tilde objects? Is the fluctuation so fast that we hear an 'average'? No, the fluctuations are often not so fast (which you can verify with a [print~] object). Seems we're just lucky that it works this way, but oh how annoying it is to not understand your own patches. Katja On Wed, Apr 30, 2014 at 12:49 AM, Simon Iten itensi...@gmail.com wrote: hi katja, i tried your patch and had a look at it. it’s beautifully programmed :-) so skilled. thanks for taking the time and it’s very interesting to see a different style and different thinking to get to the “same” outcome. i tried (with a different version of the patch) just to replace osc~ with adc~ and sang into my macbook microphone. there is no octave jumping exept for the very low notes i can sing :-) attached is a simple version with a little filtering. it’s not tested at all but this is how i did it for bass. (with other values for hip and lop of course) note that there is a lot of noise when you don’t sing or sing to quietly, this is because you amplify the shit out of the signal. so to use this you will need to add envelope following and a gate. when i tried this simple solution with your upsampled patch i got nothing :-) the signal just freezes at some high value. but i’m probably missing something very basic. cheers, simon On 29 Apr 2014, at 21:10, katja katjavet...@gmail.com wrote: Hi Simon, I'd be curious to see this adaptive filtering work in practice. Could you share a patch, once you have that working? Vocals mostly don't exceed a 3 octave range either. Only thing is, in vocals the strongest component is sometimes not the first harmonic but the second, when speaking or singing the lowest notes in the range. Katja On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote: katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
katja, you can see the error as an amplitude fluctuation in the array (i think thats the error) it gets more and more dominant with higher frequencies and at some point you hear a deep note, which seems to be the amplitude modulation coming into the hearable range. or am i wrong? i also could not tell a hearable difference in accuracy with upsampled against non upsampled version. here is the attachment again, maybe it got lost last time, or i was to tired :-) simon sinetosawtooth-II.pd Description: Binary data On 30 Apr 2014, at 23:04, katja katjavet...@gmail.com wrote: Hi Simon, Maybe it's just me but I did not find an attachment with your last post. By the way I found a bug in my upsampling method: apparently, [samplerate~] in a resampled subpatch needs some time before it reports the correct samplerate, therefore the subpatch used wrong values for filter frequency occasionally, which causes nonsense output. Attached is a fixed version. In the meantime I was wondering if upsampling is needed at all for accuracy. As Miller mentioned earlier, the error from truncating to integer nr of samples can be substantial. Attached patch 'errorsample' calculates that error and as you would expect, the error (expressed in cents) increases with frequency. However, in our patches I can't hear the error! Even if the unsig'ed frequency value shows fluctuation, the sound is stable. For comparison, you could control [phasor~] with the unsig'ed value, then you'll hear what the error really sounds like. So why don't we hear that when [phasor~] is controlled by the tilde objects? Is the fluctuation so fast that we hear an 'average'? No, the fluctuations are often not so fast (which you can verify with a [print~] object). Seems we're just lucky that it works this way, but oh how annoying it is to not understand your own patches. Katja On Wed, Apr 30, 2014 at 12:49 AM, Simon Iten itensi...@gmail.com wrote: hi katja, i tried your patch and had a look at it. it’s beautifully programmed :-) so skilled. thanks for taking the time and it’s very interesting to see a different style and different thinking to get to the “same” outcome. i tried (with a different version of the patch) just to replace osc~ with adc~ and sang into my macbook microphone. there is no octave jumping exept for the very low notes i can sing :-) attached is a simple version with a little filtering. it’s not tested at all but this is how i did it for bass. (with other values for hip and lop of course) note that there is a lot of noise when you don’t sing or sing to quietly, this is because you amplify the shit out of the signal. so to use this you will need to add envelope following and a gate. when i tried this simple solution with your upsampled patch i got nothing :-) the signal just freezes at some high value. but i’m probably missing something very basic. cheers, simon On 29 Apr 2014, at 21:10, katja katjavet...@gmail.com wrote: Hi Simon, I'd be curious to see this adaptive filtering work in practice. Could you share a patch, once you have that working? Vocals mostly don't exceed a 3 octave range either. Only thing is, in vocals the strongest component is sometimes not the first harmonic but the second, when speaking or singing the lowest notes in the range. Katja On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote: katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch
Re: [PD] Music notation in pure data
On 04/29/2014 10:44 PM, Jaime E Oliver wrote: I guess one of the nicest things about what you're showing is to do manipulations ala PWGL or open music. I'm interested in being able to make arbitrarily complex and long scores, and be able to export these as lilypond scores that can be edited and printed for someone else to play… I see. In that case I suppose you want to try to provide as much score-related data as you can for the converter to minimize your editing work. -Jonathan best, J On Apr 29, 2014, at 6:54 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/29/2014 05:28 PM, Jaime E Oliver wrote: Hi Jonathan, This is excellent work! I wonder in what direction are you taking this… As far as notation inside Pd patches-- just the demo. But I do remember Ed saying he'd initially investigated using data structures for his project. If someone wants to build some higher level tools utilizing these new features of data structure, I'm happy to fix bugs and make any improvements that would be necessary. But higher level tools are tricky-- their design depends on what you want to do with the notation. As far as the data structures, in the next release I think I'll have the basic API the way I want it. At some point I'd like to investigate drawing xlets on scalars that forward messages to the parent [struct]-- that would hide the complexity of [pointer] and friends in most cases. Finally, I'd like to find a straightforward way to load canvases with [struct] definitions as libraries. At that point people will be able to build GUI objects directly in Pd. -Jonathan best, J On Apr 29, 2014, at 1:20 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/28/2014 11:21 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data Thanks. Here's a demo of a simple Lilypond score imported into Pd-l2ork: https://jwilkes.nfshost.com/notes.webm Benefits of data structures: * no dynamic patching needed * can display the music on a normal canvas * 2d API Drawback: * if you create a new scalar, the drawing instructions have to be sent to the gui. (Even worse, ds-arrays have to redraw the entire array atm.) But one could probably just instantiate a bunch of scalars and vis them as needed. -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] CFP: Practice-Based Research in New Interfaces for Musical Expression
= Call for Papers Workshop on Practice-Based Research in New Interfaces for Musical Expression NIME 2014 Workshop: Goldsmiths, London, UK www.nime2014.org Workshop website: http://www.creativityandcognition.com/NIMEWorkshop/ Submission Deadline: May 12, 2014 (No extensions!) Notification: May 16, 2014 Workshop date: June 30, 2014 = Practitioner-researchers in new musical instrument/interface design often set themselves multiple challenges: they seek to design and implement new technologies, create and perform new works, examine and evaluate what they have done and, finally, articulate what has been learned in the process. To do this effectively requires careful consideration of the links between creative work and research. Failing to do so can lead to technical research which lacks relevance to creative practice or, conversely, creative work where the broader contribution is unclear. This workshop focuses on the relationships between creative practice and research - and blends of the two - with particular emphasis on new musical interface/instrument design. Combining practice and research leads to a series of difficult questions, including: - What constitutes a contribution in the context of practice-based research in new musical instrument/interface design? - How do we show that we have made a contribution? What kinds of evidence are appropriate? - Do we always need to evaluate our interfaces/instruments? What does evaluation mean in creative contexts? Are there fixed criteria? - What is the status of the work (performance, instrument, composition, exhibition, ...) itself? Is it possible to understand the contribution of practice-based research without experiencing the work? What is the role of documentation? - What is the place of personal reflection in relation to practice-based research? PARTICIPATION We invite 2-4 page papers or position papers for presentation and in-depth discussion. Submissions from students are welcome and encouraged. Topics may include, but are not limited to: - Case studies of practice-based research in the area of NIME. - Theoretical and conceptual framings of practice-based research in NIME contexts. - Personal reflections on past or ongoing practice-based research projects. - Techniques and methods for examining people’s experiences with new instruments/interfaces. - Approaches and methods from other domains and cultures. - Radical ideas, new approaches. Papers will be peer-reviewed and accepted papers will be published in the workshop proceedings and archived on the workshop website. After the workshop, selected participants will be invited to expand their papers for a special issue of Leonardo Transactions. Once selected, all workshop participants are required to register for at least one day of the NIME conference. You can register at http://www. nime2014.org/registration/ SUBMISSION Submit papers via EasyChair at: https://www.easychair.org/ conferences/?conf=pbrnime2014 ORGANISERS Andrew Johnston, Sam Ferguson and Ernest Edmonds Creativity and Cognition Studios, University of Technology, Sydney http://creativityandcognition.com CONTACT Please send enquiries to pbrnime2...@easychair.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not
[PD] ALSA broken pipe on pd-extended on Beaglebone?
Hi all, I am currently working on an embedded device made up of some hardware, Arduino, Beaglebone running Debian white with audio cape. I am attaching a pd file that works on a laptop. For the beaglebone, basically I change the serial port argument to 4 for [comport] but get a Broken Pipe error *ALSA input error (restart failed): Broken piperestarting input device from state 2ALSA output error (restart failed): Broken pipe* But ALSA seems to be working okay as long as only 1 application tries to use it. I followed most of the directions here to get it working ( http://www.csounds.com/journal/issue18/beagle_pi.html and http://puredata.info/docs/embedded/bbb/) I installed pd-extended by adding the repository to /etc/apt/sources.list with directions from here ( http://puredata.info/docs/faq/debian). I know sound is okay: speaker-test works ok. pd-extended works including sound, at least for a simple patch (also attached). Jack is not installed (doesn't seem necessary for single headless instance of pd-extended). Hmm...any help would be greatly appreciated! David Welch #N canvas 201 177 797 531 10; #X msg 90 35 close; #X obj 90 -27 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1 ; #N canvas 196 116 1013 612 make_my_list 1; #X obj 22 3 inlet; #X obj 298 507 outlet; #X obj 204 470 print; #X obj 293 476 route; #X obj 228 432 repack 13; #X msg 262 113 bang; #X obj 319 137 + 1; #X obj 262 138 float; #X obj 261 54 sel 10; #X obj 183 252 spigot; #X floatatom 234 227 1 0 0 0 - - -; #X msg 321 88 0; #X msg 296 21 10; #X msg 262 211 1; #X text 356 29 making sure it starts reading at beginning of line; #X msg 814 375 bang; #X obj 871 399 + 1; #X obj 814 400 float; #X floatatom 867 428 5 0 0 0 - - -; #X obj 812 302 sel 10 32; #X msg 773 245 10; #X msg 817 260 32; #X msg 772 298 11; #X msg 818 328 -1; #X obj 600 129 table frame; #X floatatom 822 507 0 0 0 0 - - -; #X msg 765 458 bang; #X obj 822 482 + 1; #X obj 765 483 float; #X floatatom 95 545 0 0 0 0 - - -; #X msg 48 467 bang; #X obj 105 491 + 1; #X obj 48 492 float; #X obj 115 516 mod 100; #X obj -19 570 tabwrite frame2; #X obj 678 129 table frame2; #X text 769 38 comment; #X obj 167 292 zl group 67; #X obj 163 324 sprintf %c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c ; #X obj 263 175 sel 1; #X connect 0 0 8 0; #X connect 0 0 9 0; #X connect 3 0 1 0; #X connect 3 1 1 0; #X connect 4 0 1 0; #X connect 5 0 7 0; #X connect 6 0 7 1; #X connect 6 0 39 0; #X connect 7 0 6 0; #X connect 8 0 5 0; #X connect 8 1 11 0; #X connect 9 0 37 0; #X connect 10 0 9 1; #X connect 11 0 7 1; #X connect 12 0 8 0; #X connect 13 0 10 0; #X connect 15 0 17 0; #X connect 16 0 17 1; #X connect 16 0 18 0; #X connect 17 0 16 0; #X connect 19 0 23 0; #X connect 19 1 23 0; #X connect 19 2 15 0; #X connect 20 0 19 0; #X connect 21 0 19 0; #X connect 22 0 19 0; #X connect 23 0 17 1; #X connect 23 0 15 0; #X connect 26 0 28 0; #X connect 27 0 25 0; #X connect 27 0 28 1; #X connect 28 0 27 0; #X connect 29 0 34 1; #X connect 30 0 32 0; #X connect 31 0 32 1; #X connect 31 0 33 0; #X connect 32 0 31 0; #X connect 33 0 29 0; #X connect 37 0 38 0; #X connect 38 0 1 0; #X connect 39 0 13 0; #X restore 74 84 pd make_my_list; #X obj 75 108 unpack f f f f f f f f f f f f f f f f f; #X text 109 -28 start polling; #X text 481 22 have fun!; #X text 195 -7 the poll command; #X floatatom 62 615 0 0 0 0 - - -; #X obj 66 585 env~ 16384; #X obj 283 510 *~; #X obj 384 552 line~; #X msg 438 560 0 100; #X text 475 557 off; #X obj 265 587 hip~ 5; #X msg 596 76 \; pd dsp 0; #X obj 266 623 dac~; #X obj 858 97 table array3; #X text 663 85 shut off sound; #X obj 70 532 tabplay~ \$1; #X msg 595 32 \; pd dsp 1; #X floatatom 827 613 5 0 0 0 - - -; #X obj 828 657 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X symbolatom 868 612 10 0 0 0 - - -; #X obj 823 583 key; #X obj 1165 653 soundfiler; #X floatatom 1164 680 0 0 0 0 - - -; #X text 1222 596 click here to load table; #X obj 1156 524 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 1156 551 openpanel; #X msg 1166 619 read -resize \$1 array6 \; pd dsp 1 \;; #X obj 945 29 table array4; #X obj 941 69 table array5; #X obj 945 96 table array6; #X obj 875 642 sel 97 115 100 102 106 107 108 59; #X obj 176 290 tabplay~ \$1; #X obj 414 497 loadbang; #X text 173 17 comment; #X obj 857 29 table array1; #X obj 857 68 table array2; #N canvas 17 149 450 475 modecontrol 0; #X floatatom 145 235 5 0 0 0 - - -; #X msg 177 171 0; #X text 194 128 increment; #X obj 145 207 float; #X obj 203 207 + 1; #X msg 146 129 bang; #X text 215 171 reset; #X floatatom 142 305 5 0 0 0 - - -; #X obj 143 264 mod 4; #X obj 146 346 print; #X obj 151 43 inlet; #X obj 199 312 outlet; #X connect 0 0 8 0; #X connect 1 0 3 1; #X connect 3 0 0 0; #X connect 3 0 4 0; #X connect 4 0 3 1; #X connect 5 0 3 0; #X
Re: [PD] ALSA broken pipe on pd-extended on Beaglebone?
Alsa is only supposed to work with One application at a Time. Am 29.04.2014 um 17:15 schrieb David Welch nicederangem...@gmail.com: Hi all, I am currently working on an embedded device made up of some hardware, Arduino, Beaglebone running Debian white with audio cape. I am attaching a pd file that works on a laptop. For the beaglebone, basically I change the serial port argument to 4 for [comport] but get a Broken Pipe error ALSA input error (restart failed): Broken pipe restarting input device from state 2 ALSA output error (restart failed): Broken pipe But ALSA seems to be working okay as long as only 1 application tries to use it. I followed most of the directions here to get it working (http://www.csounds.com/journal/issue18/beagle_pi.html and http://puredata.info/docs/embedded/bbb/) I installed pd-extended by adding the repository to /etc/apt/sources.list with directions from here (http://puredata.info/docs/faq/debian). I know sound is okay: speaker-test works ok. pd-extended works including sound, at least for a simple patch (also attached). Jack is not installed (doesn't seem necessary for single headless instance of pd-extended). Hmm...any help would be greatly appreciated! David Welch musicalquilt_28Apr14.pd simple_PD_test.pd ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ALSA broken pipe on pd-extended on Beaglebone?
I am only using it with one app with is pd-extended. On Tue, Apr 29, 2014 at 11:23 AM, Simon Iten itensi...@gmail.com wrote: Alsa is only supposed to work with One application at a Time. Am 29.04.2014 um 17:15 schrieb David Welch nicederangem...@gmail.com: Hi all, I am currently working on an embedded device made up of some hardware, Arduino, Beaglebone running Debian white with audio cape. I am attaching a pd file that works on a laptop. For the beaglebone, basically I change the serial port argument to 4 for [comport] but get a Broken Pipe error *ALSA input error (restart failed): Broken piperestarting input device from state 2ALSA output error (restart failed): Broken pipe* But ALSA seems to be working okay as long as only 1 application tries to use it. I followed most of the directions here to get it working ( http://www.csounds.com/journal/issue18/beagle_pi.html and http://puredata.info/docs/embedded/bbb/) I installed pd-extended by adding the repository to /etc/apt/sources.list with directions from here ( http://puredata.info/docs/faq/debian). I know sound is okay: speaker-test works ok. pd-extended works including sound, at least for a simple patch (also attached). Jack is not installed (doesn't seem necessary for single headless instance of pd-extended). Hmm...any help would be greatly appreciated! David Welch musicalquilt_28Apr14.pd simple_PD_test.pd ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music notation in pure data
INScore works great for me http://inscore.sourceforge.net/ Tim 2014-04-29 5:21 GMT+02:00 Max abonneme...@revolwear.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ALSA broken pipe on pd-extended on Beaglebone?
Hi, more precisely, The number of simultaneous audio streams (called an application in your message) depends on the soundcard hardware mixer and the driver. In the case of the BeagleBone, this probably sums as 1 hardware mixer == 1 application at a time. Cheers, Charles Simon Iten wrote: Alsa is only supposed to work with One application at a Time. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music notation in pure data
On 04/28/2014 11:21 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data Thanks. Here's a demo of a simple Lilypond score imported into Pd-l2ork: https://jwilkes.nfshost.com/notes.webm Benefits of data structures: * no dynamic patching needed * can display the music on a normal canvas * 2d API Drawback: * if you create a new scalar, the drawing instructions have to be sent to the gui. (Even worse, ds-arrays have to redraw the entire array atm.) But one could probably just instantiate a bunch of scalars and vis them as needed. -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from -
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On
Re: [PD] ALSA broken pipe on pd-extended on Beaglebone?
Well, the follow up to this is that I was able to resolve the problem by installing pure data (Vanilla), pd-cyclone, pd-comport with apt-get. Added /usr/lib/pd/extra/cyclone to the search path (-lib cyclone didn't work for some reason). And it works! I wonder if that means there's something wrong with pd-extended (which seems to be rather recently ported to ARM)? best, Dave On Tue, Apr 29, 2014 at 1:10 PM, Charles Goyard c...@fsck.fr wrote: Hi, more precisely, The number of simultaneous audio streams (called an application in your message) depends on the soundcard hardware mixer and the driver. In the case of the BeagleBone, this probably sums as 1 hardware mixer == 1 application at a time. Cheers, Charles Simon Iten wrote: Alsa is only supposed to work with One application at a Time. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Hi Simon, I'd be curious to see this adaptive filtering work in practice. Could you share a patch, once you have that working? Vocals mostly don't exceed a 3 octave range either. Only thing is, in vocals the strongest component is sometimes not the first harmonic but the second, when speaking or singing the lowest notes in the range. Katja On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote: katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~]
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
That is certainly true with bass (electric or upright) as well. (I'm watching this discussion with fascination!) Phil On 4/29/14, 12:10 PM, katja wrote: Hi Simon, I'd be curious to see this adaptive filtering work in practice. Could you share a patch, once you have that working? Vocals mostly don't exceed a 3 octave range either. Only thing is, in vocals the strongest component is sometimes not the first harmonic but the second, when speaking or singing the lowest notes in the range. Katja On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote: katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One
Re: [PD] Music notation in pure data
Hi Jonathan, This is excellent work! I wonder in what direction are you taking this… best, J On Apr 29, 2014, at 1:20 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/28/2014 11:21 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data Thanks. Here's a demo of a simple Lilypond score imported into Pd-l2ork: https://jwilkes.nfshost.com/notes.webm Benefits of data structures: * no dynamic patching needed * can display the music on a normal canvas * 2d API Drawback: * if you create a new scalar, the drawing instructions have to be sent to the gui. (Even worse, ds-arrays have to redraw the entire array atm.) But one could probably just instantiate a bunch of scalars and vis them as needed. -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
hi katja, i tried your patch and had a look at it. it’s beautifully programmed :-) so skilled. thanks for taking the time and it’s very interesting to see a different style and different thinking to get to the “same” outcome. i tried (with a different version of the patch) just to replace osc~ with adc~ and sang into my macbook microphone. there is no octave jumping exept for the very low notes i can sing :-) attached is a simple version with a little filtering. it’s not tested at all but this is how i did it for bass. (with other values for hip and lop of course) note that there is a lot of noise when you don’t sing or sing to quietly, this is because you amplify the shit out of the signal. so to use this you will need to add envelope following and a gate. when i tried this simple solution with your upsampled patch i got nothing :-) the signal just freezes at some high value. but i’m probably missing something very basic. cheers, simon On 29 Apr 2014, at 21:10, katja katjavet...@gmail.com wrote: Hi Simon, I'd be curious to see this adaptive filtering work in practice. Could you share a patch, once you have that working? Vocals mostly don't exceed a 3 octave range either. Only thing is, in vocals the strongest component is sometimes not the first harmonic but the second, when speaking or singing the lowest notes in the range. Katja On Tue, Apr 29, 2014 at 7:58 PM, Simon Iten itensi...@gmail.com wrote: katja, exactly! i filter the input based on the output of the pitch detection. i used this for quite some time with my doublebass (but with a pickup per string) and it works perfectly. i get no octave jumps or glitches at all. the version i shared here is planned to be used for vocals, i have to see if it works as good… the trick is not to filter too much in order to “let through” new notes but enough to filter out strong overtones (mainly octaves). it also helps to have filters in parallel. and of course you cut the range before that in order to fit your input. on a bass string this is very easy since on a double-bass you have a 3 octave range per string you can cut many frequencies before even starting filtering. this is how i did it and it worked. i adapted this system from the gr300 also. there it’s even easier. just two filters per string. one in the lower section (0-7th fret and one from 7-22 fret) they get switched via transistors based on the output voltage of the p/v circuit. they are 2nd order bandpass filters. cheers, simon On 29 Apr 2014, at 19:37, katja katjavet...@gmail.com wrote: Hi Simon, See attachment for an upsampled version. I used a 6th order lo pass filter with cut off at 1/4 of the original sampling rate. This seems to work with max. 8 times upsampling. Period length error is then limited to 1/8 sample. You mentioned adaptive filtering of a real life input signal. Are you planning to control filter cut off frequency with the pitch detection result? Did you already try that? I wonder how that could work at all, because the pitch result comes only after the adaptive filter. Katja On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten itensi...@gmail.com wrote: Katja thanks for your Inputs! Will Look at the Patch tonight. Simple lowpass Filtering? I tried to upsample with a Block object but the biquad object stopped outputting Pulses. If you don't mind doing a Version with upsampling that would be fantastic. Well i just copied from the Gr300 schematic, so no credits for me :) Am 29.04.2014 um 13:12 schrieb katja katjavet...@gmail.com: Hi Simon, So your method counts samples per (zero-crossing) cycle, is what I learned from studying the patch. Very nice how you do this with tilde objects. It seems possible to get equivalent result with only one [rpole~], when using the positive pulse as trigger for [samphold~] and with two samples delay for [rpole~]. You get the integrator's maximum everytime. See attached patch. Of course it still counts integer number of samples. Upsampling would indeed improve accuracy. An upsampled signal needs filtering to remove spectral images, did you try that? Katja On Tue, Apr 29, 2014 at 8:10 AM, simon itensi...@gmail.com wrote: nice changes with expr~ ! but i think you missed the point of the beginning of the patch. read in my first e-mail for an explanation of what this patch does exactly. it is an gr300 analog guitar synthesizer clone (well one voice of it). it is intended for real-life signals so there needs to be an adaptive filter in the beginning (with the pitch info we get from the two rpole~ objects) and the signal needs to be squared to get the longest possible sustain (envelope is re added later obviously). also i think response is faster when squared, or not? thanks for the changes, greatly appreciated! simon Well i know exactly what the Patch does... I just dont know why the two numbers before the
Re: [PD] Music notation in pure data
On 04/29/2014 05:28 PM, Jaime E Oliver wrote: Hi Jonathan, This is excellent work! I wonder in what direction are you taking this… As far as notation inside Pd patches-- just the demo. But I do remember Ed saying he'd initially investigated using data structures for his project. If someone wants to build some higher level tools utilizing these new features of data structure, I'm happy to fix bugs and make any improvements that would be necessary. But higher level tools are tricky-- their design depends on what you want to do with the notation. As far as the data structures, in the next release I think I'll have the basic API the way I want it. At some point I'd like to investigate drawing xlets on scalars that forward messages to the parent [struct]-- that would hide the complexity of [pointer] and friends in most cases. Finally, I'd like to find a straightforward way to load canvases with [struct] definitions as libraries. At that point people will be able to build GUI objects directly in Pd. -Jonathan best, J On Apr 29, 2014, at 1:20 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/28/2014 11:21 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data Thanks. Here's a demo of a simple Lilypond score imported into Pd-l2ork: https://jwilkes.nfshost.com/notes.webm Benefits of data structures: * no dynamic patching needed * can display the music on a normal canvas * 2d API Drawback: * if you create a new scalar, the drawing instructions have to be sent to the gui. (Even worse, ds-arrays have to redraw the entire array atm.) But one could probably just instantiate a bunch of scalars and vis them as needed. -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music notation in pure data
I guess one of the nicest things about what you're showing is to do manipulations ala PWGL or open music. I'm interested in being able to make arbitrarily complex and long scores, and be able to export these as lilypond scores that can be edited and printed for someone else to play… best, J On Apr 29, 2014, at 6:54 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/29/2014 05:28 PM, Jaime E Oliver wrote: Hi Jonathan, This is excellent work! I wonder in what direction are you taking this… As far as notation inside Pd patches-- just the demo. But I do remember Ed saying he'd initially investigated using data structures for his project. If someone wants to build some higher level tools utilizing these new features of data structure, I'm happy to fix bugs and make any improvements that would be necessary. But higher level tools are tricky-- their design depends on what you want to do with the notation. As far as the data structures, in the next release I think I'll have the basic API the way I want it. At some point I'd like to investigate drawing xlets on scalars that forward messages to the parent [struct]-- that would hide the complexity of [pointer] and friends in most cases. Finally, I'd like to find a straightforward way to load canvases with [struct] definitions as libraries. At that point people will be able to build GUI objects directly in Pd. -Jonathan best, J On Apr 29, 2014, at 1:20 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/28/2014 11:21 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data Thanks. Here's a demo of a simple Lilypond score imported into Pd-l2ork: https://jwilkes.nfshost.com/notes.webm Benefits of data structures: * no dynamic patching needed * can display the music on a normal canvas * 2d API Drawback: * if you create a new scalar, the drawing instructions have to be sent to the gui. (Even worse, ds-arrays have to redraw the entire array atm.) But one could probably just instantiate a bunch of scalars and vis them as needed. -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] best format for send/receive between iOS and libPD
I've got a six voice synth, each with about 20 variable parameters, and then sequence data, etc... and all of this data is being stored by the objective C front-end of my app. can someone tell me, hopefully from experience, what the best format is to send a lot of pattern data between obj C and libPD ??? should i package all the data as one huge list, or break it all into individual variables, or is it ok to organize it into groups for ease of management. my plan was to send messages like this from obj C: to [r instr1_pattern_data] : [vol 0.8, pan 0.5, pitch 0.75, param1 0.99 ... etc] actually, i'm not the one doing the C coding, i'm, just doing the pd side, but i have to prepare things on my end to make it flow as well as possible. Overall, i think there about 1400 values that need to be passed for every pattern, so it probably does need to be as well streamlined as possible. cheers for any help Matt ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah!
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large
Re: [PD] How to read I2C sensors?
Sounds great! I'll have to get the sensors first now (I was waiting to see if it would work at all) and see how far I'll get with it. Thanks Ingo Von: Ivica Bukvic [mailto:i...@vt.edu] Gesendet: Sonntag, 27. April 2014 23:27 An: Ingo Cc: Alexandros Drymonitis; pd-list Betreff: Re: AW: [PD] How to read I2C sensors? Check out also pd-l2ork k12 documentation where you can learn more about lots of pots RPi shield that gives you essentially 8 capacitive channels via the aforesaid mcp3008 d/a chip. This is what pd-l2ork essentially supports out of box. To access k12 mode start it with appropriate shortcut or simply type pd-l2ork -k12 HTH On Apr 27, 2014 3:52 PM, Ingo i...@miamiwave.com wrote: Thanks Ivica, I'll check out pd-l2ork. I might use a Raspberry Pi for that purpose anyway. I need some capacitive sensors that work without actually touching them. All I found was using I2C. Ingo Von: Ivica Bukvic [mailto:i...@vt.edu] Gesendet: Sonntag, 27. April 2014 20:38 An: Ingo Cc: Alexandros Drymonitis; pd-list Betreff: Re: [PD] How to read I2C sensors? I forget what i2c uses driverwise, but if it is spidev, in pd-l2ork you have disis_spi external that allows for reading data from mcp3008 8-channel ad converter. The external is specifically designed for Raspberry Pi build of pd-l2ork, but I don't see a reason why it could not be compiled for vanilla Pd as well. Perhaps it can be also used with your setup? On Apr 27, 2014 1:53 PM, Ingo i...@miamiwave.com wrote: Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo i...@miamiwave.com wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Music notation in pure data
Is there a working music notator in PD? pp Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2070 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter
Re: [PD] Music notation in pure data
I think somebody had one using Gem and dynamic patching. I've got a demo using svg-style drawing instructions in Pd-l2ork. I'm almost finished working on nested svg groups-- at that point one should be able to output a page of Lilypond notation to svg and write an importer to convert to a Pd patch. -Jonathan On Monday, April 28, 2014 5:36 PM, Pagano, Patrick p...@digitalworlds.ufl.edu wrote: Is there a working music notator in PD? pp Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2070 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music notation in pure data
I've been using this external of mine which is certainly ongoing work for converting pitch-duration pairs into Lilypond Scores. Here is the c code and an os x binary: http://www.jaimeoliver.pe/archives/2827 Pitch is expressed in midi and duration in multiples of a smaller unit of reference. If the smallest duration is a 32nd, a duration of 4 will give you an 8th note. I hope to improve it over the summer and get chords and tuplets which are not there just yet, but most importantly to make readable notations (i.e. get the beat to be easy to view…) Anyway, all comments are welcome at this stage... best, J On Apr 28, 2014, at 8:07 PM, Jonathan Wilkes jancs...@yahoo.com wrote: I think somebody had one using Gem and dynamic patching. I've got a demo using svg-style drawing instructions in Pd-l2ork. I'm almost finished working on nested svg groups-- at that point one should be able to output a page of Lilypond notation to svg and write an importer to convert to a Pd patch. -Jonathan On Monday, April 28, 2014 5:36 PM, Pagano, Patrick p...@digitalworlds.ufl.edu wrote: Is there a working music notator in PD? pp Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2070 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music notation in pure data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
Well i know exactly what the Patch does... I just dont know why the two numbers before the Addition Need to be -1 And -2 :-) Will Look at your Version asap. Cheers Am 29.04.2014 um 02:00 schrieb Alexandre Torres Porres por...@gmail.com: I have no idea what the patch is doing either, but I was able to clean it a lot. many things that didn't need to be there cheers 2014-04-28 3:52 GMT-03:00 Simon Iten itensi...@gmail.com: roman, thanks for your inputs. i tried both fexpr and expr and sticked to fexpr at some point, don’t know why though. will change it back! (i remember reading that fexpr was more expensive but also more precise) to make the whole thing work with real world signals (bass guitar in my case) you have to add an adaptive filter in the beginning of the chain (which is very easy because you get the frequency information hehe…) this will filter out overtones and prevent octave jumping. thanks simon On 28 Apr 2014, at 08:39, Roman Haefeli reduz...@gmail.com wrote: That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!)
[PD] pitch to voltage
dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon sinetosawtooth.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UDOO Quad and Generic Guitar to USB link issues
do you use the hardware or the plugin tab in the pd preferences? i found that i had to use the plugin and not the hardware to get results without distortion. also you should use debian hard float image and not linaro, it works better with puredata. and, i would not use jack but alsa directly with puredata. On 11 Apr 2014, at 01:54, Carlos Sanchez csanchez...@gmail.com wrote: Neat project sir! I have tried what you mentioned Brian and I cant get the system to even play sounds with the right device. Using aplay file.wav works with the default output but when i try to specify the output like so aplay -D hwplug;2,0 file.wav nothing comes up. I got these commands somewhere on the net, can you vouch for them? Also, when listing the devices with alsamixer, my soundcard lists a mic input which is odd since it has a mono in and stereo out... If this is of any use, here is the output of aplay -l: List of PLAYBACK Hardware Devices card 0: vt1613audio [vt1613-audio], device 0: HiFi vt1613-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxhdmisoc [imx-hdmi-soc], device 0: IMX HDMI TX mxc-hdmi-soc-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 My soundcard is the card 2 and I can not get any sound out of it via aplay! On Tue, Apr 8, 2014 at 5:26 PM, Brian Fay ovaltinevor...@gmail.com wrote: The reason I suggested trying arecord | aplay is because it would be running input and output simultaneously. In Audacity, you're doing one after the other. Unfortunately, I'm not sure exactly what is going wrong here. Does your soundcard work as expected on other computers? Was it fine on the BeagleBone Black? On the Raspberry Pi, I'm running a multi-effects pedal, all built in Pd. There's two parallel chains of processes, (each can run up to eight effects). The effects I'm using are a looper, delay, waveshaper distortion, flanger, granular synthesis (sort of limited implementation), reverb, and EQ. I'm controlling things with a QuNeo MIDI controller and a push button attached to the GPIO pins on the Pi. By default, each of the eight effects in each chain are set to bypass, which simply passes the signal onto the next effect. However, you can adjust this on the fly for the effects to be whatever you want, so I can set up something like: Chain A: looper - distortion - flanger - delay - granular - reverb - EQ - bypass - output Chain B: delay - bypass - bypass - bypass - bypass - bypass - bypass - bypass - output I can independently control volume of each chain, so I could use Chain A to build up some sort of droning ambience, and then solo over it using Chain B. In practice, there is definitely a limit to the ability of the Raspberry Pi. I think the example I just mentioned would probably run, but if I try throwing too many effects on at once, (flanger, reverb, distortion, and granular are all pretty intensive), I will start getting glitches - huge crackles and jitters in audio. Turning off a few effects will stop the glitches, but I all I can do to prevent them is to be conservative about how many effects I turn on. Just uploaded a little demo to Soundcloud of a recording I made with a somewhat similar FX setup to what I mentioned. It was recorded with my cell-phone, so it's a bit awful sound quality-wise (also really really quiet, whoops...). https://soundcloud.com/ovaltine-vortex/raspberry-improv If you're curious about the patches and stuff, it's all here, but it's hard-coded to MIDI values on the QuNeo and might be a bit confusing: https://github.com/YottaSecond/thesisRepo On Sun, Apr 6, 2014 at 2:37 PM, Carlos Sanchez csanchez...@gmail.com wrote: Hey list, Thanks for your prompt replies and helpfulness! I could not get qjackctl to work, the audio will not go through and the PD CPU load gets abnormally high at around 67%... I had already played with the sample rate and I had noticed that augmenting the frequency yields better results but the noise was still very present. The sound card itself works correctly with Audacity so I am sure it would work with the arecord and aplay commands Brian suggested. Weirdly, it is only with PD that it is struggling... On a more encouraging note, as Brian suggested, it seems that the problem (or one possibility) is the duplex audio. I haven't thought about using the card as an output only device before and it did work! But afterwards, I was not able to change the settings back and use the noisy duplex audio any more, I was only able to switch the output devices... @Brian: What type of software are you using for the signal processing with the Raspberry Pi? I am very curious because I had first attempted to build this project on a BeagleBone Black but the heavy PD patches made it unstable or
Re: [PD] pitch to voltage
That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pitch to voltage
Sorry for the double answer, but this also occurs to me: To improve accuracy, measure both halves of the cycle and add them. To improve further, upsample the whole mess, say by a factor of 16. Doint both of those would improve the theoretical resolution by a factor of 32. (Of course, you still have the guitar's own variation from cycle to cycle to worry about :) M On Sun, Apr 27, 2014 at 03:56:18AM -0700, Miller Puckette wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pitch to voltage
so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pitch to voltage
crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] How to read I2C sensors?
I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pitch to voltage
ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pitch to voltage
Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth patch. set your sound card to 44100 or change the 22050 in fexpr~ to half the sampling frequency. i would really appreciate if somebody could have a look at this, thanks, simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to read I2C sensors?
What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo i...@miamiwave.com wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to read I2C sensors?
Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo i...@miamiwave.com wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to read I2C sensors?
I forget what i2c uses driverwise, but if it is spidev, in pd-l2ork you have disis_spi external that allows for reading data from mcp3008 8-channel ad converter. The external is specifically designed for Raspberry Pi build of pd-l2ork, but I don't see a reason why it could not be compiled for vanilla Pd as well. Perhaps it can be also used with your setup? On Apr 27, 2014 1:53 PM, Ingo i...@miamiwave.com wrote: Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo i...@miamiwave.com wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pitch to voltage
sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because the samphold~ object is inaccurate. but i then saw that the sawtooth wave from the rpole~ object has no constant amplitude even with the input frequency not changing. so it seems that either rpole~ or change~ is not accurate. or the problem is that i sample in the middle of the rising and not at the top ( as described earlier) attached the sinetosawtooth
Re: [PD] How to read I2C sensors?
Thanks Ivica, I'll check out pd-l2ork. I might use a Raspberry Pi for that purpose anyway. I need some capacitive sensors that work without actually touching them. All I found was using I2C. Ingo Von: Ivica Bukvic [mailto:i...@vt.edu] Gesendet: Sonntag, 27. April 2014 20:38 An: Ingo Cc: Alexandros Drymonitis; pd-list Betreff: Re: [PD] How to read I2C sensors? I forget what i2c uses driverwise, but if it is spidev, in pd-l2ork you have disis_spi external that allows for reading data from mcp3008 8-channel ad converter. The external is specifically designed for Raspberry Pi build of pd-l2ork, but I don't see a reason why it could not be compiled for vanilla Pd as well. Perhaps it can be also used with your setup? On Apr 27, 2014 1:53 PM, Ingo i...@miamiwave.com wrote: Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo i...@miamiwave.com wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to read I2C sensors?
On 2014-04-27 13:52, Ingo wrote: Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. If the machine Pd is running on has an I2C port and is running linux then you can use spidev to access it. Otherwise you need to use a serial connection to an off-board microcontroller like the arduino or teensy or FRDM-KL25Z to relay messages between the I2C and USB serial connections. A lot of motherboards have I2C but it's mainly used for the temperature sensors and you don't get access via any header. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo i...@miamiwave.com wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to read I2C sensors?
Check out also pd-l2ork k12 documentation where you can learn more about lots of pots RPi shield that gives you essentially 8 capacitive channels via the aforesaid mcp3008 d/a chip. This is what pd-l2ork essentially supports out of box. To access k12 mode start it with appropriate shortcut or simply type pd-l2ork -k12 HTH On Apr 27, 2014 3:52 PM, Ingo i...@miamiwave.com wrote: Thanks Ivica, I'll check out pd-l2ork. I might use a Raspberry Pi for that purpose anyway. I need some capacitive sensors that work without actually touching them. All I found was using I2C. Ingo Von: Ivica Bukvic [mailto:i...@vt.edu] Gesendet: Sonntag, 27. April 2014 20:38 An: Ingo Cc: Alexandros Drymonitis; pd-list Betreff: Re: [PD] How to read I2C sensors? I forget what i2c uses driverwise, but if it is spidev, in pd-l2ork you have disis_spi external that allows for reading data from mcp3008 8-channel ad converter. The external is specifically designed for Raspberry Pi build of pd-l2ork, but I don't see a reason why it could not be compiled for vanilla Pd as well. Perhaps it can be also used with your setup? On Apr 27, 2014 1:53 PM, Ingo i...@miamiwave.com wrote: Thanks! Could be a possibility but I was hoping for an object that would be able to read I2C directly without adding an arduino since most smaller arm boards do have some I2C pins onboard. Ingo Von: Alexandros Drymonitis [mailto:adr...@gmail.com] Gesendet: Sonntag, 27. April 2014 19:00 An: Ingo Cc: pd-list Betreff: Re: [PD] How to read I2C sensors? What if you use the Wire library in Arduino and then collect the info in Pd with [comport]? On Sun, Apr 27, 2014 at 2:06 PM, Ingo i...@miamiwave.com wrote: I have been using an arduino with [comport] (pduino) to read out sensors so far and want to use a I2C sensor board for some other sensors soon. Can [comport] connect to the I2C interface or is there another object in Pd-extended that can do that? Thanks! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon sinetosawtooth.pd Description: Binary data On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah! in the example patch i used the falling edges of the square wave to trigger the sample and hold. this samples the sawtooth amplitude after half the rising. (this is also why i have 22050 in fexpr~ and not 44100) i could not figure out how to sample the peak of the sawtooth, so suggestions here are very welcome. now to the problem: the extracted frequency does not exactly correspond to the input frequency. it is pretty close at low frequencies but gets worse at higher frequencies. the factor is not constant. at even higher frequencies (around 5000 hertz) the reported frequency gets totally out of control. i first thought this is because
[PD] anything pd related happening in NYC from May 19-27?
or unrelated? electronic music shows, analog or digital. let's hang out and stuff. Will there be a patching circle in May? -- www.epicjefferson.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Patching Circle] Generative Musical Apps this Friday!
Hi Epic, the next patching circle will be on May 22 at ITP/NYU, 721 Broadway, 4th floor. Cheers! Sofy Yuditskaya s~ http://yuditskaya.com On Sat, Apr 26, 2014 at 2:50 PM, Epic Jefferson jeffreyconcepc...@gmail.com wrote: Hey Sofy, I'll be in NY from May 19-27. When is the patching circle? On Tue, Apr 8, 2014 at 2:36 PM, sonia yuditskaya marysgh...@gmail.comwrote: *Patching Circle* *Fri, April 116:30pm* *Conference Room* Embedded Generative Music Systems on Android and iOS with Chris McCormick and Dan Wilcox. Learn how to embed Pure Data on your Android or iPhone. The New York City Patching Circle is an free alternating monthly meeting and salon open to anyone who is working or interested in media programming and audiovisual performance. We mostly use Pd and Max/MSP, but all are welcome. Beginners and Experienced welcome. Open to everyone, students, the public, unicorns. Work on personal projects, professional projects, school projects, ask for help, help others, or just patch quietly to yourself in a room full of other people patching patches and helping other people patch. Each month there will be informal salon, featuring demonstrations of projects, performances and systems in the process of being built. The format will include short performances, artist talks about process and performance techniques and QA depending on time availability. The salon is openly curated with the intent of being as inclusive as possible and participation is open all practitioners working in realtime media. Sofy Yuditskaya s~ http://yuditskaya.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.epicjefferson.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
