Zachary Seldess

First, I know this isn't a proper bug report.

I've had to revert back to Max 5.0.4 due to several serious problems that popped up in some rather large patches when installing 5.0.5 (I can't post the patches and I don't have time to isolate, unfortunately - hence my reinstallation of 5.0.4). BUT, I'm hoping other people have experienced similar problems, and maybe someone will have some ideas (C74 people, enjoy your short vacation! Maybe when you come back someone can respond to this.)

Before I describe the problems, know that I've done reinstalls of the software before finally giving up. I'll be testing on different machines today, hopefully, and I'll post back with my results.

So, in a few different patches that use both MSP and openGL I intermittently had Max objects with on/off states just turn off. For example, my qmetro driving jitter rendering, and many BUT NOT ALL of the peakamp~ objects (each in their own instance of a poly~) in my patch would stop outputing. The audio would go on unaffected. In order to fix this, I would have to turn the DAC off and then on again. That would take care of the peakamp~s.

Again, I've had this behavior occur in three or four very different patches that use audio and openGL - I know it's not a flaw in the programming. Simply having a qmetro randomly turn off is strange. The peakamp~s in all situations have an argument (essentially causing automated banging of the object), so there seems to be a relation here. But it's strange that not all peakamp~ stop functioning.

I'm sorry I haven't had time to more clearly debug, my time has to be spent finishing projects for clients. When I'm not under tight deadlines, I'll reinstall 5.0.5 and spend some time trying to isolate and reproduce in a patch that can be posted.

In the meantime though... anyone experienced random turning off of qmetro, metro, peakamp~, clocker, etc.?

First, I know this isn't a proper bug report. 

max-5-0-5-problems

Yes, if you could please send us some example steps to reproduce when 

you find the time, we would appreciate it.

Yes, if you could please send us some example steps to reproduce when  
you find the time, we would appreciate it.

Just to note that I entered the forum searching for a mention of the same problem.

It is hard to debug and replicate because it happens after a random amount of time, sometimes a minute, sometimes a half hour.

I am using a clocker to drive a huge patch that involves audio and OpenGL and video processing, in which after a while I get the clocker turning itself off. Its happened on three different computers till now, though all were running Max 5.0.5.

I'll of course post back if I manage to build a patch that recreates this which is small and transmittable, because the one running now is ginormous and dependent on commercial vst plugins.

I'm with you... it's hard to replicate. I just had it happen again today at a presentation in a meeting with some people at ASCAP! I need to prioritize this and come up with some way of reproducing the behavior for the folks at '74 to witness. Anyways, let us know if you manage to create a postable example.

OK! I've got a patch that consistently exhibits the behavior that I described earlier in this thread. The last four times I opened this patch I had various qmetros/peakamp~s/meter~s freeze up at about:

An interesting note: I tried to document this as a movie using iSHowU, but I can't reproduce. Running that software must be changing some event priorities in Max or in the OS (well, at least something must be changing - it doesn't matter whether I use the soundflower drivers to route audio to iShowU or not - never get the buggy behavior).

Ilias and others, PLEASE try this patch and report back if things break for you (be patient, there's no way to predict how long it takes to manifest). To be honest, I'm surprised more people haven't reported this issue. This has unfortunately been a huge thorn in my side since 5.0.4

OK! I've got a patch that consistently exhibits the behavior that I described earlier in this thread. The last four times I opened this patch I had various qmetros/peakamp~s/meter~s freeze up at about:
1st: 5 seconds
2nd: 1 min
3rd: 30 seconds
4th: 30 seconds

I have only been able to reproduce on my Macbook Pro (no problems on my Windows machine... how often does one get to say that ;p)

MacBook Pro 2.5 GHz Intel Core 2 Duo
4 GB RAM
GeForce 8600M GT, 512 MB VRAM
Leopard 10.5.5


Just to confirm that your patch very quickly locks up also on my machine. Replacing the qmetro with a clocker, which is the object I had trouble with, gives the same behaviour.

I am running a recent download of Max, 5.0.5 36470, on a Dell M4400 with vista which is kept up to date. Graphics card may be a factor here, it is an Nvidia Quadro FX 770M, running on Forceware 176.07 drivers.

Hope this helps, and Zachary, thanks for the test patch!

Just to confirm that your patch very quickly locks up also on my machine. Replacing the qmetro with a clocker, which is the object I had trouble with, gives the same behaviour. 

Thanks for the example, but I can't seem to reproduce on a very 

similar system. When this next happens, could you open Activity 

Monitor and take a thread snapshot ("Sample Process"), and send along 

the report? It sounds like there's some threading issue where we've 

reached a deadlock in the scheduler thread, and this might provide us 

Also, things like overdrive, scheduler in audio interrupt, and DSP 

settings would be useful for us to try and recreate the scenario.

Thanks for the example, but I can't seem to reproduce on a very  
similar system. When this next happens, could you open Activity  
Monitor and take a thread snapshot ("Sample Process"), and send along  
the report? It sounds like there's some threading issue where we've  
reached a deadlock in the scheduler thread, and this might provide us  
with the clues we need.

Also, things like overdrive, scheduler in audio interrupt, and DSP  
settings would be useful for us to try and recreate the scenario.

I can't reproduce the buggy behavior on the the Windows XP partition of my MacBook Pro either - only on the Mac OS side. But it's happening for Ilias, and he's using Vista. Hmmm... Hopefully we'll get more feedback from people on this, and maybe the folks at Cycling'74 will be able to reproduce.

I only noticed this behavior occurring starting with 5.0.4 (I know I posted earlier it was only 5.0.5, but after reverting to 0.4 eventually ran into the same issues). Also, as far as Mac, I've only tested on Leopard 10.5.5

Here are 8 sample process snapshots from activity monitor. I reproduced the behavior twice at each setting. I've included notes on each setting in the zip file, along with the sample process files. So far, the problem only occurs when overdrive and audio interrupt are disabled.

Joshua, can you reproduce with overdrive off?

I tried yesterday with overdrive on and didn't see any problems. Tried today with overdrive off and got a stack overflow pointing to peakamp~. Perhaps that helps?

I tried yesterday with overdrive on and didn't see any problems. Tried today with overdrive off and got a stack overflow pointing to peakamp~.  Perhaps that helps? 

On Nov 24, 2008, at 6:52 AM, Zachary Seldess wrote:

> Joshua, can you reproduce with overdrive off?

Unfortunately, not. If you can get us the process sample, that would 

>
> Joshua, can you reproduce with overdrive off?

Unfortunately, not. If you can get us the process sample, that would  
help.

On Nov 24, 2008, at 8:19 AM, David Beaudry wrote:

> I tried yesterday with overdrive on and didn't see any problems. 

> Tried today with overdrive off and got a stack overflow pointing to 

If in fact peakamp~ is somehow the problem, another thing to try, 

might be to use something like abs~ -> slide~ -> snapshot~ in place of 

peakamp~. In general, I'd recommend that sort of msp network for 

envelope following anyway, since it's more of a continuous filter. 

However, if you can get us more info on how peakamp~ might be a 

problem or not, we can try to find the source of the problem.

>
> I tried yesterday with overdrive on and didn't see any problems.  
> Tried today with overdrive off and got a stack overflow pointing to  
> peakamp~.  Perhaps that helps?

If in fact peakamp~ is somehow the problem, another thing to try,  
might be to use something like abs~ -> slide~ -> snapshot~ in place of  
peakamp~. In general, I'd recommend that sort of msp network for  
envelope following anyway, since it's more of a continuous filter.  
However, if you can get us more info on how peakamp~ might be a  
problem or not, we can try to find the source of the problem.

Thanks for the advice, will try to avoid peakamp~ in these situations for now.

"Unfortunately, not. If you can get us the process sample, that would help."

Did you see my attachment from a few posts ago? Several process samples in there. Are they not what you're looking for? Let me know and I'll resend/redo whatever it takes. Thanks.

Thanks for the advice, will try to avoid peakamp~ in these situations for now. 

On Nov 24, 2008, at 8:53 AM, Zachary Seldess wrote:

> Did you see my attachment from a few posts ago? Several process 

> samples in there. Are they not what you're looking for? Let me know 

> and I'll resend/redo whatever it takes. Thanks.

Oh, fooey, I've only been looking at my email list. I assume some 

messages are not making it through to me (spam filter?). I see it on 

the forum now. Sorry about that. Will examine. Unfortunately the 

overdrive off more likely indicates something like scheduler backlog - 

> corruption than thread deadlock, however that might not be the 

case. You might try using a larger sampling interval, if infact it is 

a scheduler backlog problem (i.e. generating more events than can be 

It might be something else, and I'll keep digging.

> Did you see my attachment from a few posts ago? Several process  
> samples in there. Are they not what you're looking for? Let me know  
> and I'll resend/redo whatever it takes. Thanks.

Oh, fooey, I've only been looking at my email list. I assume some  
messages are not making it through to me (spam filter?). I see it on  
the forum now. Sorry about that. Will examine. Unfortunately the  
overdrive off more likely indicates something like scheduler backlog - 
 > corruption than thread deadlock, however that might not be the  
case. You might try using a larger sampling interval, if infact it is  
a scheduler backlog problem (i.e. generating more events than can be  
processed in realtime).

This is just a shot in the dark, but is "probing" turned on in the Debug menu?

peakamp~ isn't the sole problem. Replacing with abs~ --> slide~ --> snapshot~ causes the same behavior. I'm away from my computer now, but I'll post that modified patch later.

Vector sizes are also not the problem, it happens at every combination of i/o and sig vector sizes that I've tried (this is detailed in the sample process attachment from earlier).

I'm quite sure probing is off, but I'll get back on that later tonight when I'm able to check.

I've made a few versions of the bugTest patch (1a, 1b, 2a, 2b). Version 1 uses peakamp~ and version 2 uses abs~-->slide~-->snapshot~. When I enable automatic reporting for either peakamp~ or snapshot~ (by adding an argument), I get the buggy behavior. If I manually bang these objects though, the problem does not occur (so far). This is what I initially suspected, the problem seems to be with MSP objects that translate to Max and have the option of automatic reporting (meter~, snapshot~, peakamp~).

1a and 2a use automatic reporting (bug behavior occurs)

1b and 2b use manual banging (no bug behavior)

1a and 2a use automatic reporting (bug behavior occurs)
1b and 2b use manual banging (no bug behavior)

Thanks for these further refinements. These highlight that something 

about calling clock_delay from the MSP thread while overdrive is off. 

I wish I could reproduce here to better establish the issue, but will 

look through this code path for things which might be going wrong.

For the meantime, I would suggest either using your polling 

approach, or turning on overdrive. Sorry for the inconvenience.

Thanks for these further refinements. These highlight that something  
about calling clock_delay from the MSP thread while overdrive is off.  
I wish I could reproduce here to better establish the issue, but will  
look through this code path for things which might be going wrong.

  For the meantime, I would suggest either using your polling  
approach, or turning on overdrive. Sorry for the inconvenience.

Max 5.0.5 problems