2008/1/20, Roman Haefeli <reduzierer@yahoo.de>:

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