[PD] SOLVED!!! Re: pitch to voltage SOLVED!!!

katja katjavetter at gmail.com
Tue Apr 29 19:37:43 CEST 2014

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.


On Tue, Apr 29, 2014 at 3:44 PM, Simon Iten <itensimon at 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 <katjavetter at 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 <itensimon at 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 <porres at 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 <itensimon at 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 <reduzent at 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 <itensimon at 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 <itensimon at 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 <itensimon at 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 <msp at ucsd.edu> wrote:
>>>>>>>>>>>>>>> That is an excellent, witty way to measure pulse withs using
>>>>>>>>>>>>>>> only tilde obects - my hat's off to you.
>>>>>>>>>>>>>>> The methond only has limited accuracy since its measurement is
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> samples.   For instance, a 1/2 cycle of a 440-hz. tone at 44.1
>>>>>>>>>>>>>>> kHz is
>>>>>>>>>>>>>>> only 50 samples, so there's only 2% accuracy.  That's about
>>>>>>>>>>>>>>> 1/3 of a
>>>>>>>>>>>>>>> half tone (30-ish cents) which would sound horribly out of
>>>>>>>>>>>>>>> tune.
>>>>>>>>>>>>>>> There's an alternative sine-to-sawtooth recipe described here:
>>>>>>>>>>>>>>> http://msp.ucsd.edu/Publications/icmc10.pdf
>>>>>>>>>>>>>>> This is the basis of my guitar processing patch, smeck, but
>>>>>>>>>>>>>>> should be more
>>>>>>>>>>>>>>> broadly useful.  But it has its own limitations: the sawtooth
>>>>>>>>>>>>>>> you get out
>>>>>>>>>>>>>>> is wiggly if the input sn't a pure sinusoid.
>>>>>>>>>>>>>>> There's also the possibility of simply pitch tracking with
>>>>>>>>>>>>>>> sigmund~.  Use
>>>>>>>>>>>>>>> a maximum frequency around 6000 and a maximum of 6 partals
>>>>>>>>>>>>>>> (default 50!)
>>>>>>>>>>>>>>> for best results.
>>>>>>>>>>>>>>> cheers
>>>>>>>>>>>>>>> M
>>>>>>>>>>>>>>> On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote:
>>>>>>>>>>>>>>>> dear list,
>>>>>>>>>>>>>>>> i have a strange problem with my “sinetosawtooth” patch.
>>>>>>>>>>>>>>>> it is basically a version of the pitch to voltage conversion
>>>>>>>>>>>>>>>> used in the old gr300 guitar synths from roland.
>>>>>>>>>>>>>>>> i cut out all the clutter to make it easier to look at and
>>>>>>>>>>>>>>>> understand. (cut out the adaptive filtering at the input since i use a sine
>>>>>>>>>>>>>>>> wave for this example and not a guitar string)
>>>>>>>>>>>>>>>> here is how it works (or should):
>>>>>>>>>>>>>>>> -an input signal gets amplified by a large factor and
>>>>>>>>>>>>>>>> clipped. this squares the input.
>>>>>>>>>>>>>>>> -the square wave is converted to pulses.
>>>>>>>>>>>>>>>> -the pulses from the rising of the square wave are used to
>>>>>>>>>>>>>>>> set and reset an accumulating filter (rpole~)
>>>>>>>>>>>>>>>> this results in a sawtooth wave that varies in amplitude
>>>>>>>>>>>>>>>> depending on the frequency of the input.
>>>>>>>>>>>>>>>> -a sample and hold samples the peak of the sawtooth and holds
>>>>>>>>>>>>>>>> it until the next peak occurs. this, after a conversion gives us the input
>>>>>>>>>>>>>>>> frequency. yeah!
>>>>>>>>>>>>>>>>   in the example patch i used the falling edges of the
>>>>>>>>>>>>>>>> square wave to trigger the sample and hold. this samples the sawtooth
>>>>>>>>>>>>>>>> amplitude after half the rising. (this is also why i have  22050 in fexpr~
>>>>>>>>>>>>>>>> and not 44100) i could not figure out how to sample the peak of the
>>>>>>>>>>>>>>>> sawtooth, so suggestions here are very welcome.
>>>>>>>>>>>>>>>> now to the problem:
>>>>>>>>>>>>>>>> the extracted frequency does not exactly correspond to the
>>>>>>>>>>>>>>>> input frequency. it is pretty close at low frequencies but gets worse at
>>>>>>>>>>>>>>>> higher frequencies. the factor is not constant. at even higher frequencies
>>>>>>>>>>>>>>>> (around 5000 hertz) the reported frequency gets totally out of control.
>>>>>>>>>>>>>>>> i first thought this is because the samphold~ object is
>>>>>>>>>>>>>>>> inaccurate. but i then saw that the sawtooth wave from the rpole~ object has
>>>>>>>>>>>>>>>> no constant amplitude even with the input frequency not changing. so it
>>>>>>>>>>>>>>>> seems that either rpole~ or change~ is not accurate.
>>>>>>>>>>>>>>>> or the problem is that i sample in the middle of the rising
>>>>>>>>>>>>>>>> and not at the top ( as described earlier)
>>>>>>>>>>>>>>>> attached the sinetosawtooth patch. set your sound card to
>>>>>>>>>>>>>>>> 44100 or change the 22050 in fexpr~ to half the sampling frequency.
>>>>>>>>>>>>>>>> i would really appreciate if somebody could have a look at
>>>>>>>>>>>>>>>> this,
>>>>>>>>>>>>>>>> thanks, simon
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> Pd-list at iem.at mailing list
>>>>>>>>>>>>>>>> UNSUBSCRIBE and account-management ->
>>>>>>>>>>>>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>>> _______________________________________________
>>>>>> Pd-list at iem.at mailing list
>>>>>> UNSUBSCRIBE and account-management ->
>>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>> _______________________________________________
>>>>> Pd-list at iem.at mailing list
>>>>> UNSUBSCRIBE and account-management ->
>>>>> http://lists.puredata.info/listinfo/pd-list
>>>> _______________________________________________
>>>> Pd-list at iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> http://lists.puredata.info/listinfo/pd-list
>>> <sinetosawtooth-II.pd>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>> <sinetosawtooth2.pd>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sinetosawtooth3.pd
Type: text/x-puredata
Size: 4501 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140429/724e9fae/attachment.bin>

More information about the Pd-list mailing list