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