barney lenihan

So I've been making a drum sequencer patch in Max for one of my University assignments and I keep on running into a pretty confusing and frustrating problem. Currently I'm using Global transport to control the tempo of my drum sequencers and to test them I've been plugging in pretty simple 4 to the floor rhythms to make sure they are doing what I need them to be doing. What I have been finding is that regardless of the bpm I play them or what patch they are triggering (kick, snare, high hat and so on) I get really noticeable fluctuations between each beat. What should be a straight 4 to the floor kick at 120bpm ends up sounding like a 4 to the floor kick with someone constantly adjusting the tempo up and down. I'm really not too sure where I'm going wrong and I guess I'm just curious if anyone else has run into a similar problem?

So I've been making a drum sequencer patch in Max for one of my University assignments and I keep on running into a pretty confusing and frustrating problem. Currently I'm using Global transport to control the tempo of my drum sequencers and to test them I've been plugging in pretty simple 4 to the floor rhythms to make sure they are doing what I need them to be doing.  What I have been finding is that regardless of the bpm I play them or what patch they are triggering (kick, snare, high hat and so on) I get really noticeable fluctuations between each beat. What should be a straight 4 to the floor kick at 120bpm ends up sounding like a 4 to the floor kick with someone constantly adjusting the tempo up and down. I'm really not too sure where I'm going wrong and I guess I'm just curious if anyone else has run into a similar problem? 

Hi All, 
So I've been making a drum sequencer patch in Max for one of my University assignments and I keep on running into a pretty confusin

global-transport-timing-problems

How could one tell anything, without any infos about that

Maybe you are not syncing things at all, or whatever ?

Even metro / counter based simple tik tak would stay absolutely tight.

How could one tell anything, without any infos about that
transports and drum sequencers.
Maybe you are not syncing things at all, or whatever ?
Even metro / counter based simple tik tak would stay absolutely tight.



make sure that "Scheduler in Overdrive" and "Audio Interrupt" are both checked under Options -> Audio Status. If those are on you can trade off timing vs cpu with the "Signal Vector Size" option, smaller sizes will have tighter timing but tax your computer more.

Also, it depends on your patch: if you use messages to trigger UI objects, which then trigger playback objects, you might get timing fluctuations. That's expected: UI objects are dealt with in a low priority thread in Max.

If you have both Scheduler in Overdrive and Audio Interrupt, you should get good timing (depending on your patch, even with large vector sizes). Try it.

You can get good timing with Scheduler in Overdrive ON while Audio Interrupt is OFF, but then the Vector Size plays a bigger role. Try it.

If Scheduler in Overdrive is Off, then all messages are processed at low priority, like the UI objects. This is what you don't want.

Also, it depends on your patch: if you use messages to trigger UI objects, which then trigger playback objects, you might get timing fluctuations. That's expected: UI objects are dealt with in a low priority thread in Max.
If you have both Scheduler in Overdrive and Audio Interrupt, you should get good timing (depending on your patch, even with large vector sizes). Try it.
You can get good timing with Scheduler in Overdrive ON while Audio Interrupt is OFF, but then the Vector Size plays a bigger role. Try it.
If Scheduler in Overdrive is Off, then all messages are processed at low priority, like the UI objects. This is what you don't want.

Hmm thats a good point about the UI objects. It would be nice to get more clarity about when the "low priority for ui objects" comes into play. For example, I use matrixctl as a kind of grid sequencer a lot. I'm essentially just using this to query the getcolumn message. I'm assuming this is happening in high priority since there are no UI updates but it would be nice to know for sure. In general I havent noticed any timing problems there with the exception of crazy large patches. I guess I assumed that for some of these objects that could be performing a "through" kind of operation, like putting a number box in a patch would not slow things down, it would just be the UI update would be lower priority but the output would still be high priority.

Hmm thats a good point about the UI objects. It would be nice to get more clarity about when the "low priority for ui objects" comes into play. For example, I use matrixctl as a kind of grid sequencer a lot. I'm essentially just using this to query the getcolumn message. I'm assuming this is happening in high priority since there are no UI updates but it would be nice to know for sure. In general I havent noticed any timing problems there with the exception of crazy large patches.  I guess I assumed that for some of these objects that could be performing a "through" kind of operation, like putting a number box in a patch would not slow things down, it would just be the UI update would be lower priority but the output would still be high priority. 

I would wonder about matrixctl since it's a kind of old object.

I would assume though, that objects like [live.grid] and [live.step] are designed to work in the Scheduler (with only the graphics and the mouse interactions being low-priority). It would be interesting to test that.

Indeed, that's a good question, Nick.
I would wonder about matrixctl since it's a kind of old object.
I would assume though, that objects like [live.grid] and [live.step] are designed to work in the Scheduler (with only the graphics and the mouse interactions being low-priority). It would be interesting to test that.

I would like to believe that existing objects have been modernized under the hood where applicable. I've done quite a bit of testing by just recording midi events into a DAW and checking them against the grid. In general the timing is quite good, and has also improved over the years.

I have noticed if I have a lot of things going, there are potential hiccups and everything might be delayed a bit, which is a pain to correct after the fact. At certain level of patch complexity it becomes quite tricky to determine what is Max sputtering out and what is a bug in my patch.

I would like to believe that existing objects have been modernized under the hood where applicable. I've done quite a bit of testing by just recording midi events into a DAW and checking them against the grid. In general the timing is quite good, and has also improved over the years. 

I have noticed if I have a lot of things going, there are potential hiccups and everything might be delayed a bit, which is a pain to correct after the fact.  At certain level of patch complexity it becomes quite tricky to determine what is Max sputtering out and what is a bug in my patch.

This sounds like you almost certainly accidentally going into the lower priority UI thread. I use very large sequencers I've built in Scheme for Max and in Max objects, and have done careful tests of accuracy and latency, and the clocking in Max 7 and 8 is rock solid. However, it takes not much activity on your machine at all to delay low priority thread events, and this will show up as fluctuations. You should trace though your patch to ensure you are in the right thread.

My experiences with timing tests match Jean-Francois's observations too. I have done extensive timing tests and it's definitely something wrong in your patch or setup.

This sounds  like you almost certainly accidentally going into the lower priority UI thread. I use very large sequencers I've built in Scheme for Max and in Max objects, and have done careful tests of accuracy and latency, and the clocking in Max 7 and 8 is rock solid.  However, it takes not much activity on your machine at all to delay low priority thread events, and this will show up as fluctuations. You should trace though your patch to ensure you are in the right thread. 

My experiences with timing tests match Jean-Francois's observations too. I have done extensive timing tests and it's definitely something wrong in your patch or setup. 

Global transport timing problems.