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
>
#N canvas 95 168 926 532 10;
#X obj 29 203 rpole~;
#X obj 27 55 *~ 1e+07;
#X obj 141 407 dac~;
#X obj 27 31 osc~ 220;
#X floatatom 27 9 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 568 18 graph;
#X obj 31 455 tabwrite~ \$0-array;
#X obj 30 258 samphold~;
#X obj 74 152 *~ -1;
#X obj 74 176 +~ 1;
#X obj 28 177 sig~ 1;
#X obj 39 429 metro 100;
#X obj 39 404 loadbang;
#X text 148 10 sine to sawtooth with frequency extraction all signal
level;
#X obj 27 102 biquad~ 0 0 1 -1 0;
#X obj 162 333 phasor~;
#X obj 373 236 mtof;
#X obj 373 262 / 220;
#X obj 373 211 + 57;
#X floatatom 373 183 5 0 0 0 - - -;
#X floatatom 373 287 5 0 0 0 - - -;
#X text 319 156 adjust for second voice (halftones);
#X text 168 449 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 608 435 s \$0-array;
#X msg 608 408 arrayviewlistnew;
#X obj 27 78 clip~ 0 1;
#X text 85 53 scale up;
#X floatatom 419 253 5 0 0 0 - - -;
#X obj 27 127 expr~ $v1==1;
#X obj 30 287 expr~ 44100/$v1;
#X text 556 11 2;
#X text 551 456 -1;
#X text 93 75 convert sine to rectangle (0 - 1);
#X text 454 227 midinote;
#X floatatom 419 228 5 0 0 0 - - -;
#X text 453 253 frequency (Hz);
#X text 106 126 upward slope;
#X obj 44 315 unsig~;
#X floatatom 44 340 5 0 0 0 - - -;
#X text 149 99 differentiator: convert rectangles to pulses (-1 and
1);
#X obj 29 230 zexy/z~ 2;
#X text 74 201 integrator (sample counter);
#X obj 30 367 phasor~;
#X text 94 228 2 samples delay;
#X text 78 339 Hz;
#X obj 187 356 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 1100 1;
#X floatatom 197 383 5 0 0 0 - - -;
#X obj 128 383 *~ 0;
#X obj 163 383 *~ 0;
#X text 92 258 hold nr of samples per cycle;
#X text 128 281 compute frequency (SR 44K1 assumed);
#X obj 162 303 *~ 1;
#X text 411 287 frequency ratio;
#X connect 0 0 42 0;
#X connect 1 0 27 0;
#X connect 3 0 1 0;
#X connect 4 0 3 0;
#X connect 7 0 31 0;
#X connect 8 0 9 0;
#X connect 9 0 0 1;
#X connect 10 0 0 0;
#X connect 11 0 6 0;
#X connect 12 0 11 0;
#X connect 14 0 30 0;
#X connect 15 0 50 0;
#X connect 16 0 17 0;
#X connect 16 0 29 0;
#X connect 17 0 20 0;
#X connect 18 0 16 0;
#X connect 18 0 36 0;
#X connect 19 0 18 0;
#X connect 20 0 53 1;
#X connect 26 0 25 0;
#X connect 27 0 14 0;
#X connect 30 0 8 0;
#X connect 30 0 7 1;
#X connect 31 0 39 0;
#X connect 31 0 44 0;
#X connect 31 0 53 0;
#X connect 39 0 40 0;
#X connect 42 0 7 0;
#X connect 44 0 6 0;
#X connect 44 0 49 0;
#X connect 47 0 48 0;
#X connect 47 0 49 1;
#X connect 47 0 50 1;
#X connect 49 0 2 0;
#X connect 50 0 2 1;
#X connect 53 0 15 0;
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Reply via email to