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

Simon Iten itensimon at gmail.com
Tue Apr 29 15:44:57 CEST 2014 

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>

More information about the Pd-list mailing list