Bump (with pictures to attract attention ;-)

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? Cheers Roger

Bump (with a 'please').

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

Cheers Roger

Hi Roger,

Sorry for not seeing this sooner

I can reproduce in Max 6 as well.

We'll have a look at it.

Cheers

Andrew

And the story is....

phasor~ @lock requires Scheduler in Audio Interrupt

Seems to work fine with that on here

-A

Not here :-( Cheers Roger

Ah yes I can see it in 5.1.9 too. But not in 6.

Sorry - I would say there is no chance this will be addressed.

-A

OK, thanks for looking. Time to move to Max 6, then! Cheers Roger