i noticed that msp is not accurate at all. here's a little patch of a timed phasor:

the intervals fluctuate betweenn 998 and 1010 milliseconds on my computer.

i tried it with my internal soundcard as well as my focusrite saffire pro 10 wich doesn't make any difference.

i have scheduler in overdrive turned on and in audiointerrupt.

nothing running except this little patch above and safari.

i have a unibody MBP from may 2009 with 2,4ghz CPU, 2gb ram, 250gb HDD and a 256mb GPU.

i tried it with my internal soundcard as well as my focusrite saffire pro 10 wich doesn't make any difference.
i have scheduler in overdrive turned on and in audiointerrupt.
nothing running except this little patch above and safari.

i'm on mac osx 10.5.7 and max5.0.7
i have a unibody MBP from may 2009 with 2,4ghz CPU, 2gb ram, 250gb HDD and a 256mb GPU.


msp-inaccurate-as-hell-max5-0-7-bug

with scheduler in audio interrupt i get a pretty stable output (only changes from 999.9 ms to 1000.1 once every ten seconds or so).

without scheduler in interrupt i get the normal +/- 15 ms timing crapness that i have come to accept.

windows xp, crappy laptop soundcard, max 5.07

with scheduler in audio interrupt i get a pretty stable output (only changes from 999.9 ms to 1000.1 once every ten seconds or so). 

windows xp, crappy laptop soundcard, max 5.07


I would always question the method used to determine the accuracy of MSP. What if timer is not measuring the time intervals accurately while MSP is working just fine?

yes offourse. but i noticed this with different objects and just made this so you could test. so it can't be timer.

If they are all Max control objects, you wouldn't see a difference in behavior...

i don't know if you can see count~ and maxmin~ as control objects but maybe you could give it a try and tell me if this occurs on your computer too? or give me a tip about how to test it properly?

can someone please help me. i'm trying to control event's with audio for more accuracy but if msp isn't accurate it would be a waste of time.

max events are really inaccurate with timing by nature, I've never really found a decent trade off in terms of cpu/vector size/slop settings etc. Just get it the best you can and try and live with it.

max events are really inaccurate with timing by nature, I've never really found a decent trade off in terms of cpu/vector size/slop settings etc.  Just get it the best you can and try and live with it.


it ain't max events wich are buggy but msp. wich i think is very strange. also a friend of mine tested it with the patch above and it was 100% steady.

it ain't max events wich are buggy but msp. wich i think is very strange. also a friend of mine tested it with the patch above and it was 100% steady.
what could it have to do with?


i just recorded the 1Hz phasor wave to a file and loaded it in to cubase, looks ok here.

that's a good one i'll try that too. could you try recording ten or twenty cycles?

when i try 1 hertz in my paych it is very stable too only when i put floats as a frequency in phasor it gets wonky. strange?

As already mentioned in this thread, if you want to have a tight schedule of Max events you need to have Overdrive on and Scheduler in Audio interrupt on as well. In your example what you're really seeing is more an artefact of how a scheduler works, a more appropriate measure would be to use cpuclock which doesn't rely on the Max scheduler.

I tested recording the clicks from my samm~ to a Max buffer and then saved to disk. All the clicks seem to be precisely where they should be. At least over the short term, MSP seems to be sample accurate.

my overdrive and scheduler in audio interrupt are on. when i use cputimer out of the cpuclock helpfile there's is even more wonky-ness in the intervalls, but then again offcourse i need to trigger the clock with bangs coming out of a signal process:

i'm looking @ a recording of this 1.65hz phasor and the first 8 cycles seem tight on whole milliseconds but ableton does not reflect floating point milliseconds so i'm not very shure.

i'm looking @ a recording of this 1.65hz phasor and the first 8 cycles seem tight on whole milliseconds but ableton does not reflect floating point milliseconds so i'm not very shure.


as i already said it's about the floating point herzes. 1 hz works fine but 1.65 varies ±2 milliseconds wich is quite crucial for my patch.

well as you probably know floating points values are by definition, not really accurate (they are precisely inaccurate...). But unless you need a precision over an hour or so it should be totally sample accurate. You might want to check the Joshua's hr~ objects as well.

nit wrote on Thu, 02 July 2009 23:16as i already said it's about the floating point herzes. 1 hz works fine but 1.65 varies ±2 milliseconds wich is quite crucial for my patch.

well as you probably know floating points values are by definition, not really accurate (they are precisely inaccurate...). But unless you need a precision over an hour or so it should be totally sample accurate. You might want to check the Joshua's hr~ objects as well.


thanks for helping me out. i thinks your right. i h=just thought it was weird that when i timed a metro it was 100% accurate but msp not.

I think MSP is accurate. I just ran the same test with BPM 99 (beat speed 1.65 Hz) and once again, the result was accurate. My guess is that you're getting hosed as soon as you leave the signal domain.

nit wrote on Thu, 02 July 2009 22:26thanks for helping me out. i thinks your right. i h=just thought it was weird that when i timed a metro it was 100% accurate but msp not.

that would be the most plausible yes. but how can i make some kind of metro out of a phasor wich sends something like bangs on a point in phasor~?

You might not be able get the precision performance that you want from phasor~. I'd recommend having a look at my samm~ in this case.

nit wrote on Thu, 02 July 2009 22:44that would be the most plausible yes. but how can i make some kind of metro out of a phasor wich sends something like bangs on a point in phasor~?

http://www.sarc.qub.ac.uk/~elyon/LyonSoftware/MaxMSP/

im working on a patch i use to preform wich heavily relies on quantization.

i use a metronome going into onebangs left inlet and a bang from a controller in the right to quantize.

also with this kind of quantization i time the length of a recorded sample to count the frequency for a phasor wich drives the play~ object.

when i use a metro with like 1n for an argument the timing is very accurate. but if i use some signal process to create a metro with edge~ on the end to bang it is for some reason very inaccurate.

i'm no genius at all when it comes to max and only programming for a year and i'm very new to programming in the signal domain.

idealy i would like to drive my whole patch with one phasor but i really have no idea how i can manage that and the problem is that phasor won't be accurate anymore when i wan't to get bangs out if it.

the reason i wan't phasor to control everything is because of synchronization problems. when there happens anything my computer needs to think about for a while the phasor wich drives the play~ object and the 1n metro for the quantization get out of sync and that would be very crucial on stage. if it would be all driven by one phasor the whole patch would hang for a few milliseconds but everything would stay in sync wich is good enough.

could somebody maybe help me a little? and is it normal for togedge (or phasor as wel as your samm~) to cause inaccuracy?

thanks, but it doesnlt solve my problem.
im working on a patch i use to preform wich heavily relies on quantization.
i use a metronome going into onebangs left inlet and a bang from a controller in the right to quantize.
also with this kind of quantization i time the length of a recorded sample to count the frequency for a phasor wich drives the play~ object.
when i use a metro with like 1n for an argument the timing is very accurate. but if i use some signal process to create a metro with edge~ on the end to bang it is for some reason very inaccurate.
i'm no genius at all when it comes to max and only programming for a year and i'm very new to programming in the signal domain.

could somebody maybe help me a little? and is it normal for togedge (or phasor as wel as your samm~) to cause inaccuracy?


You may find it helpful to study the difference between event-based timing and signal-based timing. There is a long thread on it here: 

Incidentally, samm~ should not introduce noticeable inaccuracies. But if you think you've discovered a bug in the external, please let me know.

You may find it helpful to study the difference between event-based timing and signal-based timing. There is a long thread on it here: http://tinyurl.com/mx4tat

You may also want to check out Andrew Benson's steps~ and other externals:

https://cycling74.com/twiki/bin/view/Share/AndrewBenson

One problem with steps~ is that it's not possible (seemingly) to restart the count. Andrew, any advice on this?

You may also want to check out Andrew Benson's steps~ and other externals: 

One problem with steps~ is that it's not possible (seemingly) to restart the count. Andrew, any advice on this? 

i don't thinks samm~ is buggy. every signal path i make in max is a little bit inaccurate. i think there's something wrong with my computer or my max version. could somedbody tell me what the reason could be?

off the top of my head if you're patch behaves differently on your computer to everyone else's (just thinking back to your first posted patch) could it be clock jitter on the timing crystal on the soundcard? can you try your patch on a different soundcard?

Along the same line you may want to check what background process are running on your machine . . . just in case . . .

With Scheduler on Audio interrupt, all scheduler actions are performed in between each audio vector is processed. That means that the scheduler responsiveness depends on the vector size. 

On my system, your patch with Scheduler in audio interrupt gives me:

What your patch demonstrate is how the Scheduler is performing differently from MSP. MSP itself is precise, and does perform samples at a constant rate.

Actually, if your work with a very large vector size, you might get a more responsive Scheduler when not in audio interrupt, because then, you authorize it to perform operations even during the processing of an audio vector.

With Scheduler on Audio interrupt, all scheduler actions are performed in between each audio vector is processed. That means that the scheduler responsiveness depends on the vector size. 
On my system, your patch with Scheduler in audio interrupt gives me:

Vector Size  ***  Results from timer 
   2048              975 to 1022 ms
      2      ***     solid 1000 ms

What your patch demonstrate is how the Scheduler is performing differently from MSP. MSP itself is precise, and does perform samples at a constant rate.
Actually, if your work with a very large vector size, you might get a more responsive Scheduler when not in audio interrupt, because then, you authorize it to perform operations even during the processing of an audio vector.

I am building a signal based transport solution (including a masterphasor, subdivisions through rate~, banging with delta~ edge~, etc...). Smaller signal vector sizes improve timing. Do you think it would be a good idea to load the whole transportsystem in a poly~ with a very small vector size?

i noticed that msp is not accurate at all. here's a little patch of a timed phasor

The problem is timer. And edge~. And your DSP settings.

I tacked an lp.stacey on to your patch to get some statistical measurements of what's going on. On my host, with Scheduler in Audio Interrupt ON and a sufficiently small SigVec size (like about 4) I get the following values for time between bangs after running the patch for a couple of minutes:

It also eats a noticeable amount of CPU compared to, say a 256 SigVec. But 

 gives a standard dev between bangs of ~2.6ms (min 998.5, max 1004, mean very close to 1000; all of that after running the patch for a couple of minutes.) This is not surprising given that 256 samples is about 5ms at 44.1kHz and edge~ only sends a bang out at the end processing a SigVec's worth of samples. 

The modified patch below, requires lp.stacey from Litter Power. You can use the version from the Litter Starter Pack (URI in the .sig), it works fine despite a cosmetic warning to the Max window. (The Litter Pro Bundle gets rid of those pesky warnings).

nit wrote on Thu, 02 July 2009 16:47i noticed that msp is not accurate at all. here's a little patch of a timed phasor

It also eats a noticeable amount of CPU compared to, say a 256 SigVec. But that gives a standard dev between bangs of ~2.6ms (min 998.5, max 1004, mean very close to 1000; all of that after running the patch for a couple of minutes.) This is not surprising given that 256 samples is about 5ms at 44.1kHz and edge~ only sends a bang out at the end processing a SigVec's worth of samples. That's the main problem.

normally i use a signal vectorsize of 64 (and an I/O size of 256 but i don't thinks that matters?). i thought that was pretty small but even with a phasor of 1 hz it causes inaccuaracy of @ highest 2 ms. does it time that way with that vector size on your computers too?

when i use a signal vector size of 16 an a phasor of 1Hz the intervalls are rock solid but when i calcute in example 145bpm wich makes phasor go at 2.41667Hz the intervalls switch beteen 413.666656 an 414 ms. even with a vector size of 2 the timed intervalls sporadicly switch from 413.791656 to 413.83334 wich is a vector size i think i couldn't affort.

is this normal or is it only my computer?

i tried using the internal souncard but this gives me even more inaccuracy on all these settings i tried with my other soundcard, wich as a 'focusrite saffire pro10'. 

i also can't find any background processes wich use ramrkable much cpu or memory.

strange thing is that when i use a metro at a vector size of 64 at whaterver floating point interval(tried 4n with 145bpm, 414.75689 ms, and just 100 ms) it is rock rock solid.

when i use a signal vector size of 16 an a phasor of 1Hz the intervalls are rock solid but when i calcute in example 145bpm wich makes phasor go at 2.41667Hz the intervalls switch beteen 413.666656 an 414 ms. even with a vector size of 2 the timed intervalls sporadicly switch from 413.791656 to 413.83334 wich is a vector size i think i couldn't affort.
is this normal or is it only my computer?

i tried using the internal souncard but this gives me even more inaccuracy on all these settings i tried with my other soundcard, wich as a 'focusrite saffire pro10'. 
i also can't find any background processes wich use ramrkable much cpu or memory.

strange thing is that when i use a metro at a vector size of 64 at whaterver floating point interval(tried 4n with 145bpm, 414.75689 ms, and just 100 ms) it is rock rock solid.


even with a signal vector size of 1 it doesn't stay at the same interval!!

Allow me to suggest you start a new thread with a different title, one that describes the problems that you experience. The current thread is pretty hopeless, because at the onset you jumped to the wrong conclusion. You are measuring something of which you can not judge the precision. So if you provide a patch that shows why less then half a millisecond is so problematic, someone of this forum can give precise suggestions.

normally i use a signal vectorsize of 64... i thought that was pretty small but even with a phasor of 1 hz it causes inaccuaracy of @ highest 2 ms.

As I explained in my previous message, edge~ will only send a bang out 

If your sigvec is 64, that means no matter which sample is "responsible" for triggering edge~, the bang doesn't get sent until after the 64th sample.

This is absolutely fundamental to the way MSP communicates with the rest of the Max world. If you do not understand this, you will never be able to work with Max/MSP effectively.

nit wrote on Mon, 06 July 2009 00:56normally i use a signal vectorsize of 64... i thought that was pretty small but even with a phasor of 1 hz it causes inaccuaracy of @ highest 2 ms.

As I explained in my previous message, edge~ will only send a bang out after processing an entire signal vector.

If your sigvec is 64, that means no matter which sample is "responsible" for triggering edge~, the bang doesn't get sent until after the 64th sample. 

but in that case a signal vector size of 1 will cause it to bang the next samnple?

as i previously said, also a vector size of 1 causes little inaccuracy when timed.

but in that case a signal vector size of 1 will cause it to bang the next samnple?
as i previously said, also a vector size of 1 causes little inaccuracy when timed.


as sugested i created a new topic for this problem:

https://cycling74.com/forums/index.php?t=msg&goto=176923&rid=7765&S=e22ccec6ab0e62f2a2357c9114f81694#msg_176923

I recommend that you make the I/O Vector Size as small as possible.

msp inaccurate as hell. max5.0.7 bug?