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