roger.carruthers

Why does a phasor~ @lock 1 create issues with delta~ ?

I notice that in the phasor~.help sub-patch [p using phasor~ with a metro] a delta~ of

Please see attached patch.
Why does a phasor~ @lock 1 create issues with delta~ ?
 I notice that in the phasor~.help sub-patch [p using phasor~ with a metro] a delta~ of
cheers
Roger

phasor-lock-bug-was-wait-transport-lock-1

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?

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


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.

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.

Max 5.1.8 , OS 10.6.8 2.1 GHz Core 2 Duo MacBook and 3.06GHz Core i3 iMac

 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. 

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

phasor~ @lock requires Scheduler in Audio Interrupt

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.

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

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


Phasor~ lock bug? (was wait~ & transport @lock 1)