msp inaccurate as hell. max5.0.7 bug?
i noticed that msp is not accurate at all. here’s a little patch of a timed phasor:
----------begin_max5_patcher---------- 432.3ocyUF0aCBBDG+Y8SAgmsMfsV0k8x9brzrfJskEELJl0sl1O6SfZa2xl ilZ57EHdbd2+6GGvNWGXhXKsFBd.7LvwYmqii1jxfywucfEjso4jZsavU4Bd SAzyrTIQltgwW+REMUZBi+BzTjGvOVOsXtZDGMEAVd7eXY5.IRdchOF0EoUB tjSJn50dphQx6VoMcLdNUpyO9rQQiryp+EAol8gNHXU9MlMdJeujZjnpHHRn G.lP3qgfkJ2165pF7rjCb5asUPmFkzs5xGJYEzJKnSndZ1rdoCJ5Joi+vRmA kLzr0zC8QFeCYlaHSb+jI7eouQ2tbSsMIMRofaAFLMH9mF+YLDbEEKt2pZH2 pe7.XBZZfEUoYZte+a13A4X.9J2rqYq4sIXHASFMWRr4P.xbHHpetLLWdNB3 R4FRsn5..+2nAGomBB5CM333QSKiVevbF+6uypqQk8uxqZQSUZW.O8L.3bcl QqkLNQxZuG4BuTOkdgWaXYYTsCcpsfkUJXb4QY7K6e1qpPaTkV63QopFerJ3 NqJrUpJ7NqJjUpBeWUk9BEKT0sbFr8i8teR55i5R -----------end_max5_patcher-----------
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’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.
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
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.
check out ftm?
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.
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.
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.
|nit wrote on Thu, 02 July 2009 23:16|
|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.
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.
|nit wrote on Thu, 02 July 2009 22:26|
|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.
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~?
|nit wrote on Thu, 02 July 2009 22:44|
|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.
were can i find that?
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.
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?
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
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 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:
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?
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
The problem isn’t MSP.
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:
- Minimum: 1000.
- Maximum: 1000.
- Mean: 1000.
- Standard deviation: 0
That seems pretty accurate.-|
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.
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).
Hope this helps,
– Peter– Pasted Max Patch, click to expand. –Copy all of the following text. Then, in Max, select New From Clipboard.
----------begin_max5_patcher---------- 980.3oc4Y0zaSCCF9b6uBqbBjJU1NeZDWPvAjPHgzj3BBgbSLoFRbpRbYCPr e63X6tkAKeTVVZWWOjj5jX+7gesesyulOyYUwErJGvyAeDLa1ulOaltn5BlY ++Lmb5EwYzJ8i4DWjmyDRmEl6IYWH0k+FtDDmwnkfyWyDf30TQJWjBd8YuGr gVRyYRVYE3ILYJ3Ld5GXwfJ9OYOcWEkwEr3hsBcsgsEtgJiWqpkOWxhkFT5F DrDt.fHlS9v5SXxRH3S1WRrMmKxXRMdQ1B+RgPV2d5xpeGSw7DM3KV80mE5b 86WrUtqBfMp.ghE5m+kkbZlS8M98740GVLP0KmUUQSY+i5oUNmNXcXjlmd35 St3k9JtGzFowClzt2No2oZlhj+XCy.CGmqZvwQO9RVgpk6j3tZF65qOoOhB2 G2lrDE.QjH6sVWq4wEYEklF.tLJD5GEs3VuB0nkVkdyWKP8KbwsdUyWqgZGc kuqzKQZFqYGra5.31b.khQUQe.mUpZ3Z6PUiUwTaMtjztIYuSLUH0wnlNG2K VmumwybOArNxoj001X3m8M14cXndPRCC0mbmMzF5KBNEC+1Fwe61RYQEuZ.j 2zOdjIOZJHufctpw9GtmsYYkjFy9QGjGa3qKRGQibcGU12xLugsEGwE5nnqB mF9ES9rW1osBOEFBD8Ha5KjNCSWhNkKe2G1dG4Qk2gIg01kmNo2G5wcX3iKu yrTGObzof2gNk7NEdWwJ6OOAOufGpdmBd7bU+yFtTS6DOB1oM8ki0EA7J8lv zahvVOl.GyTAwtGxUA7Nq22O2MiMMxb26fxc5ECj6l4TG2E.g8OnbmQECXke 1DAGWhGbHI9YRpHgVl.dM66bpjWLDYHTuFPRznJCSxlu1epGA1cSVeJvrX2n 69VKiaa2M12o7uW2H.IOu6I2spSnIoZ2tUmguGzXXz+q5LQJCKIkcYWJC1nL dFkgLZ8afg6oxn6tbO0sY0VoryQH1IClNH3qN1sLbC95umeOBKOGOq9EWBdF bo+.Xo4j4CxLNgAn8j7U7TgxJmlXfDVljNjf.nIHHZ7BBfGy5xl0zphxKAn9 kFTjI0I+wpKChPtWkF8io+xr+0mHVyw5xuodUUrsLdWSY+7hfqYYBqRxEl7L t9Yp292FOzZdRBSzbx+bdxlB0hlrXnkn8gBI8bwGafR2bA8fonoGR98.IxzC Iu9btCfL41GlN.5DtGLggSOlP8gIzzio9FIndKelRLQHCATvo08961qMTglX TgFDpl3IXfCpaUcptGgnJ5nEUnIDUQCAUn6RLn5O+d9e.rmSQPF -----------end_max5_patcher-----------
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.
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.
|nit wrote on Mon, 06 July 2009 00:56|
|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 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.
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.
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:
I recommend that you make the I/O Vector Size as small as possible.