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