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
Description: Binary data
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list