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