Kasper

as we all know the accurency problems of metro (and other max 

time-related objects) I decided to build a chronometer in audio (as 

the one i am using, based on a metro 1000 and counter, reported 

during yesterday's rehersal a duration of of 29 minutes when the 

piece was 40 minutes long - which is 25% difference, not a minor 

so i decided to base the time calculation on a phasor~ 1 - which i 

think should be similar to metro 1000, but more precise.

still, when i check with a timer, it does not give a steady pulse...

is that me??? - the patch below was the only one running - on a MAC 

OSX47, max 457, a Powerbook G4 1.5Ghz... i mean that should not be 

many thanks for any help (or explaination)

#P number 334 286 108 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;

as we all know the accurency problems of metro (and other max 
time-related objects) I decided to build a chronometer in audio (as 
the one i am using, based on a metro 1000 and counter, reported 
during yesterday's rehersal a duration of of 29 minutes when the 
piece was 40 minutes long - which is 25% difference, not a minor 
problem)

so i decided to base the time calculation on a phasor~ 1 - which i 
think should be similar to metro 1000, but more precise.
still, when i check with a timer, it does not give a steady pulse...

is that me??? - the patch below was the only one running - on a MAC 
OSX47, max 457, a Powerbook G4 1.5Ghz...   i mean that should not be 
TOO MUCH for such a computer...

#P window setfont "Sans Serif" 9.;
#P number 334 286 108 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 334 253 35 196617 timer;
#P newex 334 86 39 196617 >~ 0.9;
#P button 334 163 63 0;
#P newex 334 110 36 196617 edge~;
#P user ezdac~ 468 220 512 253 0;
#P newex 334 63 55 196617 phasor~ 1;
#P connect 5 0 6 0;
#P connect 0 0 4 0;
#P connect 4 0 2 0;
#P connect 2 0 3 0;
#P connect 3 0 5 1;
#P connect 3 0 5 0;
#P window clipboard copycount 7;
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

metro-in-audio-still-not-right

i'm not an msp wizard, but my guess would be that the unsteadyness 

you are seeing is due to the 'button' and the 'timer' objects you use 

As far as I understand these matters timing within msp is very solid, 

the timing of the max-scheduler (i.e. the sending of max-messages) is 

not, and here you are using objects which live in the max-scheduled 

I am sure I do not use the right vocabulary here, and it is well 

possible I didn't understand it right anyways..

On 17 Sep 2006, at 15:24, Kasper T Toeplitz wrote:

> so i decided to base the time calculation on a phasor~ 1 - which i 

> think should be similar to metro 1000, but more precise.

> still, when i check with a timer, it does not give a steady pulse...

> is that me??? - the patch below was the only one running - on a MAC 

> OSX47, max 457, a Powerbook G4 1.5Ghz... i mean that should not 

i'm not an msp wizard, but my guess would be that the unsteadyness  
you are seeing is due to the 'button' and the 'timer' objects you use  
to check your timing..

As far as I understand these matters timing within msp is very solid,  
the timing of the max-scheduler (i.e. the sending of max-messages) is  
not, and here you are using objects which live in the max-scheduled  
world to measure msp-timing.

I am sure I do not use the right vocabulary here, and it is well  
possible I didn't understand it right anyways..

> so i decided to base the time calculation on a phasor~ 1 - which i  
> think should be similar to metro 1000, but more precise.
> still, when i check with a timer, it does not give a steady pulse...
>
> is that me??? - the patch below was the only one running - on a MAC  
> OSX47, max 457, a Powerbook G4 1.5Ghz...   i mean that should not  
> be TOO MUCH for such a computer...


In any case i did understood you, and this is also something i thought about

but, if this is the case, using ONLY a button and a timer - on a 

not-so-bad computer would create such a sloppiness???

using the same objects, but with a metro 1000 seems perfectly stable 

(see patch), driving them with audio (phaser~ -> edge~) is not...

>i'm not an msp wizard, but my guess would be that the unsteadyness 

>you are seeing is due to the 'button' and the 'timer' objects you 

>As far as I understand these matters timing within msp is very 

>solid, the timing of the max-scheduler (i.e. the sending of 

>max-messages) is not, and here you are using objects which live in 

>the max-scheduled world to measure msp-timing.

>I am sure I do not use the right vocabulary here, and it is well 

>possible I didn't understand it right anyways..

but, if this is the case, using ONLY a button and a timer - on a 
not-so-bad computer would create such a sloppiness???

using the same objects, but with a metro 1000 seems perfectly stable 
(see patch), driving them with audio (phaser~ -> edge~) is not...

>i'm not an msp wizard, but my guess would be that the unsteadyness 
>you are seeing is due to the 'button' and the 'timer' objects you 
>use to check your timing..
>
>As far as I understand these matters timing within msp is very 
>solid, the timing of the max-scheduler (i.e. the sending of 
>max-messages) is not, and here you are using objects which live in 
>the max-scheduled world to measure msp-timing.
>
>I am sure I do not use the right vocabulary here, and it is well 
>possible I didn't understand it right anyways..

I am running it now and it is not so bad... I'll tell you in an hour ;-)

according to my experience timing accuracy between Max and MSP 

depends very much on the Signal Vector Size. When using smaller 

Vector Sizes, the coordination between Max and MSP gets much tighter.

(The reason why timing in only-Max seems to be more precise is 

certainly that the mistakes apply in the same way to all Max objects, 

according to my experience timing accuracy between Max and MSP  
depends very much on the Signal Vector Size. When using smaller  
Vector Sizes, the coordination between Max and MSP gets much tighter.
(The reason why timing in only-Max seems to be more precise is  
certainly that the mistakes apply in the same way to all Max objects,  
i.e. the metro as well as the timer.)

After 23 minutes, I have an offset of less than 4 seconds, I presume 

it is due to the innacuracy of the 32 bits output of count~

I have done a new verison with JKC' hr objects, will keep you posted.

After 23 minutes, I have an offset of less than 4 seconds, I presume  
it is due to the innacuracy of the 32 bits output of count~

After 76 minutes, my hr.count~ version is 5 seconds late

After 99 minutes, my count~ version is 9 seconds late

I have a question now for under-the-hood Max people.

If I play an hour long audio file, can I expect the same mistake? 5 

seconds on 75 minutes = 0.00111111 = almost 2 cents

Not much indeed, but good to know where is it coming from: sync 

Sorry to ask questions that might be so obvious for certain, but I 

want to be very sure before telling students stupid things...

After 76 minutes, my hr.count~ version is 5 seconds late
After 99 minutes, my count~ version is 9 seconds late

If I play an hour long audio file, can I expect the same mistake? 5  
seconds on 75 minutes = 0.00111111 = almost 2 cents

Not much indeed, but good to know where is it coming from: sync  
chrystal error margin ?

Sorry to ask questions that might be so obvious for certain, but I  
want to be very sure before telling students stupid things...

>After 76 minutes, my hr.count~ version is 5 seconds late

>After 99 minutes, my count~ version is 9 seconds late

i am not as precise as you, but 3 run-through of a 40 minutes piece 

when running both a "real" chronometer (you know, hardware with fresh 

batteries in !!) and a chronometer made in max with phasor~ 1 ->

edge~ showed a difference of _maybe_ 1 second ( I mean I can not 

guarantee I switched them both on/off at exactly the same time...)

will try to run it again, for a longer period (with a heavy patch - 

using some lp.epoisse~ from the litter lib is something which is very 

bad for timing; i know it from experience!!)

>Dear all.
>
>After 76 minutes, my hr.count~ version is 5 seconds late
>After 99 minutes, my count~ version is 9 seconds late
>

i am  not as precise as you, but 3 run-through of a 40 minutes piece 
when running both a "real" chronometer (you know, hardware with fresh 
batteries in !!) and a chronometer made in max with phasor~ 1 ->
edge~ showed a difference of _maybe_ 1 second ( I mean I can not 
guarantee I switched them both on/off at exactly the same time...)

will try to run it again, for a longer period (with a heavy patch - 
using some lp.epoisse~ from the litter lib is something which is very 
bad for timing; i know it from experience!!)

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

I came to the conclusion several years ago that truly accurate timing is not possible in Max. My first attempt to write a drum machine with Max as the clock, back in 1996 had me over-using the phrase "good enough for algorithmic music." But not for techno. The timing is better now, but I haven't been able to get a tight enough clock with Max, ever. The obvious solution is to use MSP instead, and that really works. I wrote a system of externals that do sub-sample accurate clocking and interoperate through signal connections. I'm presenting a paper on them in November at the New Orleans ICMC, and expect to distribute these externals shortly thereafter.

I came to the conclusion several years ago that truly accurate timing is not possible in Max. My first attempt to write a drum machine with Max as the clock, back in 1996 had me over-using the phrase "good enough for algorithmic music." But not for techno. The  timing is better now, but I haven't been able to get a tight enough clock with Max, ever. The obvious solution is to use MSP instead, and that really works. I wrote a system of externals that do sub-sample accurate clocking and interoperate through signal connections. I'm presenting a paper on them in November at the New Orleans ICMC, and expect to distribute these externals shortly thereafter.

On Sep 17, 2006, at 10:29 AM, Pierre Alexandre Tremblay wrote:

> After 76 minutes, my hr.count~ version is 5 seconds late

> After 99 minutes, my count~ version is 9 seconds late

This is 32 bit FP resolution plain and simple. Your problem is that 

even with hr.count~, you are trying to use a *single* float number to 

represent your time if the image of your patch you posted is 

indicative of what you're actually doing. This is *not* going to 

work. The only way the output of hr.count~ is more resolute is if 

*both* the signal values are used, but that's not going to work as 

output to max. You need to modify this number to be less than 2 

raised to the 23rd power for use within the single precision range 

with integer resolution (sometimes much less depending on what you're 

looking to do with the number afterwards). You can find more 

information about single precision floating point numbers online, and 

I would suggest using multiple floating point signals for your timing 

and/or a periodic approach. e.g. use a count to count every sample in 

a second, then accumulate seconds with +=~ (as demonstrated in the 

+=~ help file or the patch at bottom). Or use something like modulo 

FWIW, I personally always use phasor~ to clock any timing information 

I wish to be sample accurate. Keeping everything in the signal 

domain. This is possible to do without developing any new objects. 

Check out the audio-rate-sequencing-looping examples folder.

> After 76 minutes, my hr.count~ version is 5 seconds late
> After 99 minutes, my count~ version is 9 seconds late

This is 32 bit FP resolution plain and simple. Your problem is that  
even with hr.count~, you are trying to use a *single* float number to  
represent your time if the image of your patch you posted is  
indicative of what you're actually doing. This is *not* going to  
work. The only way the output of hr.count~ is more resolute is if  
*both* the signal values are used, but that's not going to work as  
output to max. You need to modify this number to be less than 2  
raised to the 23rd power for use within the single precision range  
with integer resolution (sometimes much less depending on what you're  
looking to do with the number afterwards). You can find more  
information about single precision floating point numbers online, and  
in the mailing list archives.

I would suggest using multiple floating point signals for your timing  
and/or a periodic approach. e.g. use a count to count every sample in  
a second, then accumulate seconds with +=~ (as demonstrated in the  
+=~ help file or the patch at bottom). Or use something like modulo  
arithmetic in the hr objects (hr.wrap~).

FWIW, I personally always use phasor~ to clock any timing information  
I wish to be sample accurate. Keeping everything in the signal  
domain. This is possible to do without developing any new objects.  
Check out the audio-rate-sequencing-looping examples folder.

Damn, I hate when things are mathematically on par and predictable! What about the "end users" who, oh never mind. Sorry, I was pretending like it really mattered.

I have noticed all the same things mentioned above.

Damn, I hate when things are mathematically on par and predictable!  What about the "end users" who, oh never mind. Sorry, I was pretending like it really mattered.

I have noticed all the same things mentioned above.


> in may case (yes, it is a slower machine - well, a G4) it's a different 

> value at almost every tick - values seem to be between 996 and 1006...

timer is inaccurate, not phasor~, or train~.

It depends a lot on settings. with a 1001 every 16 ticks and 999 elswise 

, I'd guess Juliens setting is "scheduler in audiointerupt" and 

"overdrive on" as the accuratesse of the scheduler is not better than 

around 2 ms (also depending a lot on settings. It seems quite good. 

(timers output is even float). with the setings of Kasper you'd need to 

average the result to find out more about the correctness of the timing.

Without scheduler in audiointerrupt, there has always been a pretty big 

difference between 1000 ms of a metro and 44100 samples at 44.1 kHz...

which would result in "phasing off" between a scheduler timer and an 

audiobased time. (for example the position output of sfplay~)

My St.opwatch uses system time by the way, and wouldn't phase of either 

(or at least more in the range of years than in minutes)...

Kasper T Toeplitz wrote:
> hi
>
> in may case (yes, it is a slower machine - well, a G4) it's a different 
> value at almost every tick - values seem to be between 996 and 1006...

timer is inaccurate, not phasor~, or train~.
It depends a lot on settings. with a 1001 every 16 ticks and 999 elswise 
, I'd guess Juliens setting is "scheduler in audiointerupt" and 
"overdrive on" as the accuratesse of the scheduler is not better than 
around 2 ms (also depending a lot on settings. It seems quite good. 
(timers output is even float). with the setings of Kasper you'd need to 
average the result to find out more about the correctness of the timing.

Without scheduler in audiointerrupt, there has always been a pretty big 
difference between 1000 ms of a metro and 44100 samples at 44.1 kHz...
which would result in "phasing off" between a scheduler timer and an 
audiobased time. (for example the position output of sfplay~)
My St.opwatch uses system time by the way, and wouldn't phase of either 
(or at least more in the range of years than in minutes)...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


I've followed this topic with great interest (like a lot of people, i 

guess) and i wonder now that it seems stuck if there's any conclusions ? 

Timing is, would i say, critical, of course, and we need to trust the 

main engine we all rely on. So what is the answer for a stable & 

accurate metronome ? And for a time counter ? I, personaly, often tear 

my hair off when using a sequencer in Max (why is it always out of the 

beat, for Puckette's sake ?!). I also have unbearable troubles with 

timing issues while using multiple recorders-loopers-crossfaders, 

periodicaly have to resync all tracks, which is not very pretty in 

f.e chanfrault | aka | personal computer music

> >>>>>> |sublime music for a desperate people|

>> in may case (yes, it is a slower machine - well, a G4) it's a 

>> different value at almost every tick - values seem to be between 996 

> timer is inaccurate, not phasor~, or train~.

> It depends a lot on settings. with a 1001 every 16 ticks and 999 

> elswise , I'd guess Juliens setting is "scheduler in audiointerupt" 

> and "overdrive on" as the accuratesse of the scheduler is not better 

> than around 2 ms (also depending a lot on settings. It seems quite 

> good. (timers output is even float). with the setings of Kasper you'd 

> need to average the result to find out more about the correctness of 

> Without scheduler in audiointerrupt, there has always been a pretty 

> big difference between 1000 ms of a metro and 44100 samples at 44.1 

> which would result in "phasing off" between a scheduler timer and an 

> audiobased time. (for example the position output of sfplay~)

> My St.opwatch uses system time by the way, and wouldn't phase of 

> either (or at least more in the range of years than in minutes)...

I've followed this topic with great interest (like a lot of people, i 
guess) and i wonder now that it seems stuck if there's any conclusions ? 
Timing is, would i say, critical, of course, and we need to trust the 
main engine we all rely on. So what is the answer for a stable & 
accurate metronome ? And for a time counter ? I, personaly, often tear 
my hair off when using a sequencer in Max (why is it always out of the 
beat, for Puckette's sake ?!). I also have unbearable troubles with 
timing issues while using multiple recorders-loopers-crossfaders, 
periodicaly have to resync all tracks, which is not very pretty in 
performance...

f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|

Stefan Tiedje wrote:
> Kasper T Toeplitz wrote:
>> hi
>>
>> in may case (yes, it is a slower machine - well, a G4) it's a 
>> different value at almost every tick - values seem to be between 996 
>> and 1006...
>
> timer is inaccurate, not phasor~, or train~.
> It depends a lot on settings. with a 1001 every 16 ticks and 999 
> elswise , I'd guess Juliens setting is "scheduler in audiointerupt" 
> and "overdrive on" as the accuratesse of the scheduler is not better 
> than around 2 ms (also depending a lot on settings. It seems quite 
> good. (timers output is even float). with the setings of Kasper you'd 
> need to average the result to find out more about the correctness of 
> the timing.
>
> Without scheduler in audiointerrupt, there has always been a pretty 
> big difference between 1000 ms of a metro and 44100 samples at 44.1 
> kHz...
> which would result in "phasing off" between a scheduler timer and an 
> audiobased time. (for example the position output of sfplay~)
> My St.opwatch uses system time by the way, and wouldn't phase of 
> either (or at least more in the range of years than in minutes)...
>
> Stefan
>


>I've followed this topic with great interest (like a lot of people, 

>i guess) and i wonder now that it seems stuck if there's any 

>conclusions ? Timing is, would i say, critical, of course, and we 

>need to trust the main engine we all rely on. So what is the answer 

>for a stable & accurate metronome ? And for a time counter ? I, 

>personaly, often tear my hair off when using a sequencer in Max (why 

>is it always out of the beat, for Puckette's sake ?!). I also have 

>unbearable troubles with timing issues while using multiple 

>recorders-loopers-crossfaders, periodicaly have to resync all 

>tracks, which is not very pretty in performance...

from what i can say, since i build a time counter with phasor~, it 

seems to report time OK (it was not the case before)

as for sequencer, i don't know (yet) - here you need a really precise timing

i am also wondering what happens if one loads a reaktor sequencer 

into max (as plug-in) - will it keep the reaktor tighness or the max 

which of course is no answer for loopers/recorders

>I've followed this topic with great interest (like a lot of people, 
>i guess) and i wonder now that it seems stuck if there's any 
>conclusions ? Timing is, would i say, critical, of course, and we 
>need to trust the main engine we all rely on. So what is the answer 
>for a stable & accurate metronome ? And for a time counter ? I, 
>personaly, often tear my hair off when using a sequencer in Max (why 
>is it always out of the beat, for Puckette's sake ?!). I also have 
>unbearable troubles with timing issues while using multiple 
>recorders-loopers-crossfaders, periodicaly have to resync all 
>tracks, which is not very pretty in performance...
>
from what i can say, since i build  a time counter with phasor~, it 
seems to report time OK (it was not the case before)

i am also wondering what happens if one loads a reaktor sequencer 
into max (as plug-in) - will it keep the reaktor tighness or the max 
sloppiness???

- I don't think this particular problem was discussed in this thread 

- I was playing around with the jit.freeframe help file last night -- 

installing some freeframe plugs and playing around with them

- I loaded a movie into the jit.qt.movie object (one of the files 

- the movie played, I loaded different freeframe plugs and played 

- when I stopped the metro~ object (by either clicking off the toggle 

switch OR sending an 'off' message) the movie 'image' stopped playing 

but the audio from the movie continued playing

- known bug, new feature, something I'm missing...?

-- sorry if this has been discussed before but I wasn't able to track 

down any posts pertaining to this in my maxmsp mailbox

- I don't think this particular problem was discussed in this thread  
but:

- I was playing around with the jit.freeframe help file last night --  
installing some freeframe plugs and playing around with them
- I loaded  a movie into the jit.qt.movie object (one of the files  
from the ./patches/media folder)
- I started the metro~ object
- the movie played, I loaded different freeframe plugs and played  
around with the params a little
- when I stopped the metro~ object (by either clicking off the toggle  
switch OR sending an 'off' message) the movie 'image' stopped playing  
but the audio from the movie continued playing
- known bug, new feature, something I'm missing...?

-- sorry if this has been discussed before but I wasn't able to track  
down any posts pertaining to this in my maxmsp mailbox
thanks in advance
KIM


QuickTime special side effect. Nothing to be done about it, except to 

metro~ (in audio) still not right???