Ups...I know! My fail was to expect that phasor~ reaches a 0 value! I agree with Roman, signal to message conversion losts accurary. Would be better to use a masked phasor as synthesizer input, but how to generate a masked phasor with a M:N cycles relation? Maybe with a inverted phasor~ and samphold~?
I will try! Saludos! 2008/1/20, Roman Haefeli <[EMAIL PROTECTED]>: > > > On Sun, 2008-01-20 at 16:18 +0100, raul diaz wrote: > > > I will try this way, but anyway i'm curious about [avg~] behaviour. > > What's wrong on my "phasor-cycles-counter" patch? > > yo, i just had a quick look and it seems, that [avg~] currently isn't > working on my system (so isn't [tavg~], both don't give any output at > all). don't have the time to investigate that now. > > the first problem is the comparison with [==~ 0]. the signal from > [phasor~] reaches practically never exactly 0, unless the frequency of > it is some integer fraction of the sampling frequency and the phase is > set accordingly. this is because the moments, where the amplitude would > reach 0, is most of the time somewhere in between two subsequent > samples, but almost never exactly at sampling time. you can check that > by writing the signal of a [phasor~ 9213] to a table and have a look at > all the amplitude values. also the output of [==~ 0] will miss most of > the cycles and almost always be 0. > > the next problem is, that [avg~] updates only every 64 samples. with > higher frequencies, [avg~] would miss some the cycles. further [avg~] > outputs a float messages, which is still a float message after [change], > which overwrites the internal value of [f ]. you cannot build a counter > that is triggered by a float. you would need a bang here. a construct > like: > > [avg~] > | > [sel <somevalue>] > | > [f ] etc. > > would be more likely to work. > > please someone correct me, if this is totally non-sense, but my > experience is, that it is usually much easier to generate/synthesize a > signal than using some sample-level detection methods to compose it. > often a conversion from signal to message domain means loosing accuracy > because of the blocksize or at least the result is coming one block > late. > > roman > > > > > ___________________________________________________________ > Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de > > -- Raul Diaz Poblete ************************* [EMAIL PROTECTED] Barcelona [Spain]
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
