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
