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 - I've nver >>>>>>>>>>> seen t >>>>>>>>>>> before. I would just use biquad~ 0 0 1 -1 0 (assuming that >>>>>>>>>>> change~ simply >>>>>>>>>>> ubtracts the previous sample from teh current one as I guessed >>>>>>>>>>> from the patch :) >>>>>>>>>>> >>>>>>>>>>> M >>>>>>>>>>> >>>>>>>>>>> On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: >>>>>>>>>>>> ok tried to upsample the whole thing (after the osc~) and now >>>>>>>>>>>> change~ does nothing anymore… it just spits out the same square >>>>>>>>>>>> wave i feed >>>>>>>>>>>> in…clues? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 27 Apr 2014, at 13:05, Simon Iten <itensi...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> crosspost! sorry about the noise. thanks for the inputs i will >>>>>>>>>>>>> try to to this. not sure if i can. otherwise i will ask back if >>>>>>>>>>>>> that’s ok! >>>>>>>>>>>>> On 27 Apr 2014, at 13:03, Simon Iten <itensi...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> so if i would measure at the peak of the sawtooth and would >>>>>>>>>>>>>> upsample inside the pd patch, i would get higher resolution, >>>>>>>>>>>>>> right? >>>>>>>>>>>>>> >>>>>>>>>>>>>> any ideas how i can measure at the peak? (using the rpole >>>>>>>>>>>>>> output on both samphold inputs does not work and delaying one of >>>>>>>>>>>>>> them is >>>>>>>>>>>>>> also not working) >>>>>>>>>>>>>> >>>>>>>>>>>>>> which >>>>>>>>>>>>>> >>>>>>>>>>>>>> i would highly recommend you try this method with your gk-3 >>>>>>>>>>>>>> equipped guitar (one for each string) since you only have to >>>>>>>>>>>>>> cover a two >>>>>>>>>>>>>> octave range per string the error is tolerable. (you can add an >>>>>>>>>>>>>> offset to >>>>>>>>>>>>>> make it fit) >>>>>>>>>>>>>> On 27 Apr 2014, at 12:56, Miller Puckette <m...@ucsd.edu> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> That is an excellent, witty way to measure pulse withs using >>>>>>>>>>>>>>> only tilde obects - my hat's off to you. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The methond only has limited accuracy since its measurement is >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 >>>>>>>>>>>>>>> kHz is >>>>>>>>>>>>>>> only 50 samples, so there's only 2% accuracy. That's about >>>>>>>>>>>>>>> 1/3 of a >>>>>>>>>>>>>>> half tone (30-ish cents) which would sound horribly out of >>>>>>>>>>>>>>> tune. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There's an alternative sine-to-sawtooth recipe described here: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://msp.ucsd.edu/Publications/icmc10.pdf >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is the basis of my guitar processing patch, smeck, but >>>>>>>>>>>>>>> should be more >>>>>>>>>>>>>>> broadly useful. But it has its own limitations: the sawtooth >>>>>>>>>>>>>>> you get out >>>>>>>>>>>>>>> is wiggly if the input sn't a pure sinusoid. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There's also the possibility of simply pitch tracking with >>>>>>>>>>>>>>> sigmund~. Use >>>>>>>>>>>>>>> a maximum frequency around 6000 and a maximum of 6 partals >>>>>>>>>>>>>>> (default 50!) >>>>>>>>>>>>>>> for best results. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> cheers >>>>>>>>>>>>>>> M >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: >>>>>>>>>>>>>>>> dear list, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> i have a strange problem with my “sinetosawtooth” patch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> it is basically a version of the pitch to voltage conversion >>>>>>>>>>>>>>>> used in the old gr300 guitar synths from roland. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> i cut out all the clutter to make it easier to look at and >>>>>>>>>>>>>>>> understand. (cut out the adaptive filtering at the input since >>>>>>>>>>>>>>>> i use a sine >>>>>>>>>>>>>>>> wave for this example and not a guitar string) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> here is how it works (or should): >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -an input signal gets amplified by a large factor and >>>>>>>>>>>>>>>> clipped. this squares the input. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -the square wave is converted to pulses. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -the pulses from the rising of the square wave are used to >>>>>>>>>>>>>>>> set and reset an accumulating filter (rpole~) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> this results in a sawtooth wave that varies in amplitude >>>>>>>>>>>>>>>> depending on the frequency of the input. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -a sample and hold samples the peak of the sawtooth and holds >>>>>>>>>>>>>>>> it until the next peak occurs. this, after a conversion gives >>>>>>>>>>>>>>>> us the input >>>>>>>>>>>>>>>> frequency. yeah! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> in the example patch i used the falling edges of the >>>>>>>>>>>>>>>> square wave to trigger the sample and hold. this samples the >>>>>>>>>>>>>>>> sawtooth >>>>>>>>>>>>>>>> amplitude after half the rising. (this is also why i have >>>>>>>>>>>>>>>> 22050 in fexpr~ >>>>>>>>>>>>>>>> and not 44100) i could not figure out how to sample the peak >>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>> sawtooth, so suggestions here are very welcome. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> now to the problem: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the extracted frequency does not exactly correspond to the >>>>>>>>>>>>>>>> input frequency. it is pretty close at low frequencies but >>>>>>>>>>>>>>>> gets worse at >>>>>>>>>>>>>>>> higher frequencies. the factor is not constant. at even higher >>>>>>>>>>>>>>>> frequencies >>>>>>>>>>>>>>>> (around 5000 hertz) the reported frequency gets totally out of >>>>>>>>>>>>>>>> control. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> i first thought this is because the samphold~ object is >>>>>>>>>>>>>>>> inaccurate. but i then saw that the sawtooth wave from the >>>>>>>>>>>>>>>> rpole~ object has >>>>>>>>>>>>>>>> no constant amplitude even with the input frequency not >>>>>>>>>>>>>>>> changing. so it >>>>>>>>>>>>>>>> seems that either rpole~ or change~ is not accurate. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> or the problem is that i sample in the middle of the rising >>>>>>>>>>>>>>>> and not at the top ( as described earlier) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> attached the sinetosawtooth patch. set your sound card to >>>>>>>>>>>>>>>> 44100 or change the 22050 in fexpr~ to half the sampling >>>>>>>>>>>>>>>> frequency. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> i would really appreciate if somebody could have a look at >>>>>>>>>>>>>>>> this, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> thanks, simon >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Pd-list@iem.at mailing list >>>>>>>>>>>>>>>> UNSUBSCRIBE and account-management -> >>>>>>>>>>>>>>>> http://lists.puredata.info/listinfo/pd-list >>>>>> >>>>>> _______________________________________________ >>>>>> Pd-list@iem.at mailing list >>>>>> UNSUBSCRIBE and account-management -> >>>>>> http://lists.puredata.info/listinfo/pd-list >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pd-list@iem.at mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> http://lists.puredata.info/listinfo/pd-list >>>> >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>> >>> >>> <sinetosawtooth-II.pd> >>> >>> >>> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >> <sinetosawtooth2.pd>
#N canvas 93 172 876 529 10; #X obj 63 44 osc~ 220; #X floatatom 63 15 5 0 0 0 - - -; #N canvas 0 22 450 300 (subpatch) 0; #X array \$0-array 1000 float 0; #X coords 0 2 999 -1 320 450 1 0 0; #X restore 524 19 graph; #X obj 49 440 tabwrite~ \$0-array; #X obj 57 414 metro 100; #X obj 57 389 loadbang; #X text 111 -15 sine to sawtooth with frequency extraction all signal level; #X obj 205 343 phasor~; #X obj 238 201 mtof; #X obj 238 227 / 220; #X obj 238 176 + 57; #X floatatom 238 153 5 0 0 0 - - -; #X floatatom 238 252 8 0 0 0 - - -; #X text 275 152 adjust for second voice (halftones); #X text 47 467 phasor entirely controlled by incoming signal but freely transposable; #X msg 325 399 \; pd dsp 1; #X msg 392 399 \; pd dsp 0; #X obj 560 435 s \$0-array; #X msg 560 408 arrayviewlistnew; #X floatatom 284 218 5 0 0 0 - - -; #X text 508 11 2; #X text 503 456 -1; #X text 319 192 midinote; #X floatatom 284 193 5 0 0 0 - - -; #X text 318 218 frequency (Hz); #X obj 62 287 unsig~; #X floatatom 62 312 8 0 0 0 - - -; #X obj 48 344 phasor~; #X obj 230 366 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 0 1; #X floatatom 240 393 5 0 0 0 - - -; #X obj 171 393 *~ 0; #X obj 206 393 *~ 0; #X text 291 251 frequency ratio; #N canvas 388 167 429 554 period-detect 0; #X obj 20 22 inlet~; #X obj 67 71 samplerate~; #X floatatom 121 112 8 0 0 0 - - -; #X floatatom 144 88 8 0 0 0 - - -; #X obj 21 175 iemlib/lp6_butt~; #X obj 23 512 outlet~; #X obj 22 399 rpole~; #X obj 20 203 *~ 1e+07; #X obj 23 454 samphold~; #X obj 67 348 *~ -1; #X obj 67 372 +~ 1; #X obj 21 373 sig~ 1; #X obj 20 233 clip~ 0 1; #X text 78 201 scale up; #X obj 20 323 expr~ $v1==1; #X text 86 230 convert sine to rectangle (0 - 1); #X obj 22 426 zexy/z~ 2; #X text 67 397 integrator (sample counter); #X text 87 424 2 samples delay; #X text 85 454 hold nr of samples per cycle; #X obj 67 22 inlet; #X obj 24 480 *~ 0.25; #X obj 67 95 /; #X obj 67 46 t b f; #X msg 332 63 set 64 1 \$1; #X floatatom 77 150 8 0 0 0 - - -; #X obj 297 463 /; #X obj 297 409 t b f; #X msg 297 437 1; #X obj 67 120 * 0.25; #X text 198 88 resampled rate; #X text 178 111 audio rate; #X text 133 150 filter cut off frequency (Hz); #X obj 35 259 zexy/z~; #X obj 19 294 -~; #X text 47 293 differentiate: convert rectangles to pulses (-1 and 1); #X text 100 321 positive pulse = upward slope in original signal; #X text 77 512 period in nr of samples; #X obj 332 96 block~ 64 1 1; #X text 94 259 one sample delay; #X connect 0 0 4 0; #X connect 1 0 3 0; #X connect 1 0 22 0; #X connect 4 0 7 0; #X connect 6 0 16 0; #X connect 7 0 12 0; #X connect 8 0 21 0; #X connect 9 0 10 0; #X connect 10 0 6 1; #X connect 11 0 6 0; #X connect 12 0 34 0; #X connect 12 0 33 0; #X connect 14 0 9 0; #X connect 14 0 8 1; #X connect 16 0 8 0; #X connect 20 0 27 0; #X connect 20 0 23 0; #X connect 21 0 5 0; #X connect 22 0 2 0; #X connect 22 0 29 0; #X connect 23 0 1 0; #X connect 23 1 22 1; #X connect 23 1 24 0; #X connect 24 0 38 0; #X connect 26 0 21 1; #X connect 27 0 28 0; #X connect 27 1 26 1; #X connect 28 0 26 0; #X connect 29 0 25 0; #X connect 29 0 4 1; #X connect 33 0 34 1; #X connect 34 0 14 0; #X restore 64 71 pd period-detect; #X msg 189 15 2; #X msg 220 15 4; #X msg 252 15 8; #X obj 48 177 samplerate~; #X obj 48 151 loadbang; #X obj 48 206 sig~ 44100; #X obj 47 257 /~; #X obj 48 126 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 123 100 unsig~; #X floatatom 123 125 8 0 0 0 - - -; #X text 175 125 period length (nr of samples; #X msg 157 15 1; #X text 279 13 upsampling rate; #X text 119 205 convert to freq; #X floatatom 157 45 5 0 0 0 - - -; #X text 113 311 frequency (Hz); #X obj 184 424 dac~; #X obj 205 273 *~ 1.5; #X connect 0 0 33 0; #X connect 1 0 0 0; #X connect 4 0 3 0; #X connect 5 0 4 0; #X connect 7 0 31 0; #X connect 8 0 9 0; #X connect 8 0 19 0; #X connect 9 0 12 0; #X connect 10 0 8 0; #X connect 10 0 23 0; #X connect 11 0 10 0; #X connect 12 0 51 1; #X connect 18 0 17 0; #X connect 25 0 26 0; #X connect 27 0 3 0; #X connect 27 0 30 0; #X connect 28 0 29 0; #X connect 28 0 30 1; #X connect 28 0 31 1; #X connect 30 0 50 0; #X connect 31 0 50 1; #X connect 33 0 40 1; #X connect 33 0 42 0; #X connect 34 0 48 0; #X connect 35 0 48 0; #X connect 36 0 48 0; #X connect 37 0 39 0; #X connect 38 0 37 0; #X connect 39 0 40 0; #X connect 40 0 25 0; #X connect 40 0 27 0; #X connect 40 0 51 0; #X connect 41 0 38 0; #X connect 42 0 43 0; #X connect 45 0 48 0; #X connect 48 0 33 1; #X connect 51 0 7 0;
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
