OK, so the above was at a signal vector of 256, whereby I couldn't go above ~ 43 bpm before the locked phasor freaked out.
At a signal vector size of 64, I can get up to about 180 bpm before it all goes pear-shaped - but the clock is out by 11 ms @ 120 bpm (see pics).
The theoretical period is 125 ms; a free running phasor~ gets close enough, but with the locked phasor~ it's around 114!
I know timer isn't sample accurate, but shouldn't the error still be the same for both the free running and the locked phasor~? So why is the locked phasor~ so far out?
Is it possible to get an accurate clock this way from a transport locked phasor~, or should I just give up?
Perhaps if I make it more formally a bug report? Even if it's just to tell me I'm doing something incredibly stupid, or going crazy, I'd appreciate a reply.
I was about to give up on this, because I couldn't reproduce it on my iMac, whereas I can every time on my MacBook - but then I noticed my MacBook was at 48kHz, whereas my iMac was at 44.1 Hz.
Switching to 48kHz, I can reproduce.
Expected behaviour; a click from a phasor~ using [delta~] - [
Observed behaviour; At a sample rate of 48KHz, @lock 1 phasor~ has a frequency limit, depending on signal vector size, above which the tempo goes crazy. Furthermore, even below that limit, the measured tempo is out by several milliseconds from the theoretical value.
Method - see patch below.
Max 5.1.8 , OS 10.6.8 2.1 GHz Core 2 Duo MacBook and 3.06GHz Core i3 iMac