Max 5.0.5 problems
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.?
best,
Zachary
Hi Zachary,
Yes, if you could please send us some example steps to reproduce when
you find the time, we would appreciate it.
Thanks,
Joshua
Hi!
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.
Regards,
Ilias B.
Hi Ilias,
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.
best,
Zachary
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
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
best,
Zachary
Oh, forgot to give system specs.
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
Zachary,
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!
Regards,
Ilias B.
Hi Zach,
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.
Thanks,
Joshua
Thanks for testing Vanille.
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
Hi Joshua,
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.
best
Zachary
Thanks, Vanille.
Joshua, can you reproduce with overdrive off?
Thanks,
Zachary
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?
David
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
help.
Thanks,
Joshua
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
> 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,
Joshua
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.
best,
Zachary
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
processed in realtime).
It might be something else, and I'll keep digging.
Thanks,
Joshua
This is just a shot in the dark, but is "probing" turned on in the Debug menu?
Andrew B.
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.
Zachary
I've checked, and probing is off.
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)
best,
Zachary
Hi Zachary,
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,
Joshua