Pix - thanks for the comments. Of course, it slipped my mind to do that
- the square wave question reminded me of it, but I still managed to
miss the connection. D'...-uh. I'm not too fussed about cpu in this
instance, and do want pretty small clicks from quite low frequency
oscillators (I'm trying to experiment with impulses and feedback of
various delays). I just hadn't bothered to make a really small number
when I tried before. Actually, since writing I've realised that it
actually doesn't work as I'd expect either - comparing to really small
numbers causes it to do a bit of improv rhythm instead. Chalk one up
for the glitch list, I guess. I'll use reaktor, as I've got it and does
what I want fine in this case.
I guess it would still be nice to have a low cpu square wave, though, if
the audio compare objects are costy - would they be more expensive than,
for example, the version Frank Barknecht posted, despite looking
simpler? cpu cycles are money, people ;-).
> the reason it doesn't work is because comparing floating point numbers for
> equality rarely works. if you are doing a test for ==~ 0, the value will
> often be something very close but not exactly equal to 0. normally when
> comparing floating point numbers use test to see if they are closer than
> some very small number (normally referred to as epsilon), so you would do
> something like [phasor~] -> [<~ 0.01]... not that 0.01 is very small, but
> you get the idea.
>
> tho i'm not trying to suggest that this is a particularly good way of
> going about it. it mostly depends what you want to use the pulses for.
>
> the zexy signal comparison objects tend to be pretty cpu heavy anyhow, so
> i tend to avoid them. err... by cpu heavy, i mean if i use a few in an
> nqpoly grain, it starts to kill audio.
>
> pix.
>