roger.carruthers

I have a patch which I'm trying to update for Max5, but which is currently

producing a spinning beachball crash every time I try to run it.

It's a big and messy patch, so I'm reluctant to try and post it yet, but

I'm first of all wondering if there is anything significant about the way

it's crashing, ie. the infinite spinning beachball, as opposed to a quit

(which would at least give me a crashlog). I've let it spin away for a good

half hour or so, but always end up having to force quit. I've tried it on a

couple of different machines, with pretty much the same results.

The patch is a seq~ driven drum sequencer, and it loads OK and will even

run for a few seconds, but then it stops, and the beachball appears several

seconds later - maybe even as much as minute later. I have even been able to

stop and start the sequencer itself a few times, albeit only for a few

seconds. Trying to save the patch, once it has been run, also results in a

The same patch was working just fine in Max 4.6 - in order to update it for

Max 5, I have only had to replace a few rs.textbuttons with textbuttons, and

remove Jasch's mtx, which Max 5 definitely doesn't like (any chance of an M5

friendly version, Jasch ? I know there are specific issue that make this

problematic, but it would be great to know if it is possible - if not, I'll

The only error messages I'm getting on load are a few 'matrixctrl out of

range' messages, which I'm unable to resolve as yet, because I can only run

the thing for a few seconds at a time. I also get a few messages relating to

some SDII's that load at startup, but again, I understand that this is a M5

issue, and I can always convert these to .aif's

I have a patch which I'm trying to update for Max5, but which is currently
producing a spinning beachball crash every time I try to run it.
 It's a big and messy patch, so I'm reluctant to try and post it yet, but
I'm first of all wondering if there is anything significant about the way
it's crashing, ie. the infinite spinning beachball, as opposed to a quit
(which would at least give me a crashlog). I've let it spin away for a good
half hour or so, but always end up having to force quit. I've tried it on a
couple of different machines, with pretty much the same results.
 The patch is a seq~ driven drum sequencer, and it loads OK and will even
run for a few seconds, but then it stops, and the beachball appears several
seconds later - maybe even as much as minute later. I have even been able to
stop and start the sequencer itself a few times, albeit only for a few
seconds. Trying to save the patch, once it has been run, also results in a
spin-out.
 The same patch was working just fine in Max 4.6 - in order to update it for
Max 5, I have only had to replace a few rs.textbuttons with textbuttons, and
remove Jasch's mtx, which Max 5 definitely doesn't like (any chance of an M5
friendly version, Jasch ? I know there are specific issue that make this
problematic, but it would be great to know if it is possible - if not, I'll
know I need to find a workaround).
 The only error messages I'm getting on load are a few 'matrixctrl out of
range' messages, which I'm unable to resolve as yet, because I can only run
the thing for a few seconds at a time. I also get a few messages relating to
some SDII's that load at startup, but again, I understand that this is a M5
issue,  and I can always convert these to .aif's
 Anything here rings any bells to anyone,
TIA,
Roger

spinning-beachball-crash

On Jun 1, 2008, at 5:22 AM, Roger Carruthers wrote:

> I have a patch which I'm trying to update for Max5, but which is 

> producing a spinning beachball crash every time I try to run it.

It might be illuminating to use Activity Monitor's Sample Process 

feature to get a rough idea where it's hanging.

On Jun 1, 2008, at 5:22 AM, Roger Carruthers wrote:
> I have a patch which I'm trying to update for Max5, but which is  
> currently
> producing a spinning beachball crash every time I try to run it.

It might be illuminating to use Activity Monitor's Sample Process  
feature to get a rough idea where it's hanging.

Chris Muir
cbm@well.com	
http://www.xfade.com

How does this work exactly? I've searched in Activity Monitor help, but not

I can see that CPU usage goes from around 15%, rapidly climbing to 84% when

you start the patch and the 110% after a few seconds - whereupon our friend

the beachball appears. But how do I get any more useful info out of Activity

I'm currently copy-pasting bits of the patch together to try and find out

where the problem lies. As I said, it works fine in Max 4.5, so it seems

> On Jun 1, 2008, at 5:22 AM, Roger Carruthers wrote:

>> I have a patch which I'm trying to update for Max5, but which is

>> producing a spinning beachball crash every time I try to run it.

> It might be illuminating to use Activity Monitor's Sample Process

> feature to get a rough idea where it's hanging.

How does this work exactly? I've searched in Activity Monitor help, but not
found it.
I can see that CPU usage goes from around 15%, rapidly climbing to 84% when
you start the patch and the 110% after a few seconds - whereupon our friend
the beachball appears. But how do I get any more useful info out of Activity
Monitor ?
 I'm currently copy-pasting bits of the patch together to try and find out
where the problem lies. As I said, it works fine in Max 4.5, so  it seems
odd that it should be so wrong in Max 5,
Cheers
roger

On 01/06/2008 19:23, "Chris Muir"  wrote:

>
> On Jun 1, 2008, at 5:22 AM, Roger Carruthers wrote:
>> I have a patch which I'm trying to update for Max5, but which is
>> currently
>> producing a spinning beachball crash every time I try to run it.
>
>
> It might be illuminating to use Activity Monitor's Sample Process
> feature to get a rough idea where it's hanging.
>
> -C
>
> Chris Muir
> cbm@well.com 
> http://www.xfade.com
>
>
>
>
>
>

Like I said, it's big and ugly. And whereas I'm usually more than happy to

share, on this occasion, it wouldn't be doing anyone any favours to post it

until I've at least trimmed it down a bit,

Like I said, it's big and ugly. And whereas I'm usually more than happy to
share, on this occasion, it wouldn't be doing anyone any favours to post it
until I've at least trimmed it down a bit,
Cheers
Roger

On Jun 1, 2008, at 12:52 PM, Roger Carruthers wrote:

> How does this work exactly? I've searched in Activity Monitor help, 

Select the Max process in the Activity Monitor window.

Select Sample Process from the View menu.

> How does this work exactly? I've searched in Activity Monitor help,  
> but not
> found it.

Select the Max process in the Activity Monitor window.
Select Sample Process from the View menu.

Ah, thanks. Apple Help isn't very, er, helpful sometimes (though I apologise for not having had the brain to check the menus before posting).

OK, so I have attached a copy of the sample - anyone able to interpret this ?

Ah, thanks. Apple Help isn't very, er, helpful sometimes (though I apologise for not having had the brain to check the menus before posting).
 OK, so I have attached a copy of the sample - anyone able to interpret this ?
cheers
Roger


It looks like zigzag~ was taking up a lot of time. It might be worth opening the patch as text, and renaming zigzag~ something nonsensical. You could then at least open the patch and edit it to try and refine where the problem is.

> I have a patch which I'm trying to update for Max5, but which is currently

I'd try to start it with cmd-shift to suppress all loadbangs and see 

what happens. If that doesn't start the spinning wheel, you could try to 

find the offending init which creates the problem...

Roger Carruthers schrieb:
> I have a patch which I'm trying to update for Max5, but which is currently
> producing a spinning beachball crash every time I try to run it.

I'd try to start it with cmd-shift to suppress all loadbangs and see 
what happens. If that doesn't start the spinning wheel, you could try to 
find the offending init which creates the problem...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


OK, I've stripped the patch down to basics - just a single voice, no 3rd

It still crashes in Max 5, whereas as a much more complex version was

To reproduce, initialise with the preset, switch the dac on, load a sample

and hit the spacebar. Expected behaviour - it just keeps running 'til you

hit the spacebar again. Actual behaviour, It runs for a few seconds, then

suddenly stops, then after a few seconds the beachball appears.

OK, I've stripped the patch down to basics - just a single voice, no 3rd
party objects, graphics etc.
It still crashes in Max 5, whereas as a much more complex version was
running just fine under Max 4.6.
 To reproduce, initialise with the preset, switch the dac on, load a sample
and hit the spacebar. Expected behaviour - it just keeps running 'til you
hit the spacebar again. Actual behaviour, It runs for a few seconds, then
suddenly stops, then after a few seconds the beachball  appears.
 Any help most gratefully received,
Cheers
Roger    

On 2 juin 08, at 19:53, Roger Carruthers wrote:

> OK, I've stripped the patch down to basics - just a single voice, no 

> It still crashes in Max 5, whereas as a much more complex version was

> To reproduce, initialise with the preset, switch the dac on, load a 

> and hit the spacebar. Expected behaviour - it just keeps running 

> hit the spacebar again. Actual behaviour, It runs for a few seconds, 

> suddenly stops, then after a few seconds the beachball appears.

I miss a few abstractions (_ is replaced by prepend set, but still):

> OK, I've stripped the patch down to basics - just a single voice, no  
> 3rd
> party objects, graphics etc.
> It still crashes in Max 5, whereas as a much more complex version was
> running just fine under Max 4.6.
> To reproduce, initialise with the preset, switch the dac on, load a  
> sample
> and hit the spacebar. Expected behaviour - it just keeps running  
> 'til you
> hit the spacebar again. Actual behaviour, It runs for a few seconds,  
> then
> suddenly stops, then after a few seconds the beachball  appears.
> Any help most gratefully received,

I miss a few abstractions (_ is replaced by prepend set, but still):
newobj: ledno: No such object
newobj: tintin: No such object

There are a few stuffs missing in your patch.

The [tintin] external (the url provided on maxobject is down) and the 

Hi Roger.
There are a few stuffs missing in your patch.
The [tintin] external (the url provided on maxobject is down) and the 
abstraction (?) [ledno].
Ciao


Thanks for looking. Neither of these abstractions should affect the way the

Tintin, which is actually an abstraction that I made as a substiutue Kurt

Ralske's tintin object, which sadly never made it to UB:

> I miss a few abstractions (_ is replaced by prepend set, but still):

Thanks for looking. Neither of these abstractions should affect the way the
patch runs, but here they are anyway,
Cheers
Roger

Tintin, which is actually an abstraction that I made as a substiutue Kurt
Ralske's tintin object, which sadly never made it to UB:

> Hi Roger,
>
> I miss a few abstractions (_ is replaced by prepend set, but still):
> newobj: ledno: No such object
> newobj: tintin: No such object
>
> It doesn't crash (yet?).
> ej
>

I sympathise with the spinning ball syndrome that you're getting, I seem to

get it a lot with updating patches to max 5. Often the fault lies with not

having all the abstractions from the patch in the max searchpath. However,

if the patch runs ok for you for a few seconds this wouldn't appear to be

the case. Sorry, I can't be of more help but when I open your patch I don't

On Mon, Jun 2, 2008 at 9:06 PM, Roger Carruthers <

> Thanks for looking. Neither of these abstractions should affect the way the

> Tintin, which is actually an abstraction that I made as a substiutue Kurt

> Ralske's tintin object, which sadly never made it to UB:

> > I miss a few abstractions (_ is replaced by prepend set, but still):

I sympathise with the spinning ball syndrome that you're getting, I seem to
get it a lot with updating patches to max 5.  Often the fault lies with not
having all the abstractions from the patch in the max searchpath.  However,
if the patch runs ok for you for a few seconds this wouldn't appear to be
the case.  Sorry, I can't be of more help but when I open your patch I don't
get the spinning ball, the patch plays.
pelado

On Mon, Jun 2, 2008 at 9:06 PM, Roger Carruthers <
roger.carruthers@btinternet.com> wrote:

> Thanks for looking. Neither of these abstractions should affect the way the
> patch runs, but here they are anyway,
> Cheers
> Roger
>
> Ledno:
>
>
>
> Tintin, which is actually an abstraction that I made as a substiutue Kurt
> Ralske's tintin object, which sadly never made it to UB:
>
>
>
>
> > Hi Roger,
> >
> > I miss a few abstractions (_ is replaced by prepend set, but still):
> > newobj: ledno: No such object
> > newobj: tintin: No such object
> >
> > It doesn't crash (yet?).
> > ej
> >
>
>
>

On 3 juin 08, at 10:11, ROGER CARRUTHERS wrote:

> Thanks for your comments - this is very frustrating!

> I had the feeling that the /way/in which this patch

> was crashing was significant, as if indeed, it was

> searching for something, like a missing abstraction.

> The fact that it happens on two machines doesn't

> necessarily disprove this, because I try to keep the

> installations on the machines as synced as possible.

> And as Pelado said, it will run for a few seconds

> before it freezes, so it must be able to find all it

> In trying to strip down the patch to post here, I

> guess I'm doing as you're suggesting, rebuilding the

> patch - so far I haven't hit that gremlin, but I'll

> I guess things like this are bound to happen with

> such a significant upgrade - re-write in effect - of a

> Having said that, it does seem like I'm not the only

> one experiencing this kind of problem. Anyone at

I can't reproduce that with my current build. It doesn't seem to 

> Thanks for your comments - this is very frustrating!
> I had the feeling that the /way/in which this patch
> was crashing was significant, as if indeed, it was
> searching for something, like a missing abstraction.
> The fact that it happens on two machines doesn't
> necessarily disprove this, because I try to keep the
> installations on the machines as synced as possible.
> And as Pelado said, it will run for a few seconds
> before it freezes, so it must be able to find all it
> needs to run.
> In trying to strip down the patch to post here, I
> guess I'm doing as you're suggesting, rebuilding the
> patch - so far I haven't hit that gremlin, but I'll
> just have to keep at it.
> I guess things like this are bound to happen with
> such a significant upgrade - re-write in effect - of a
> programming tool.
> Having said that, it does seem like I'm not the only
> one experiencing this kind of problem. Anyone at
> Cycling care to comment...?

I can't reproduce that with my current build. It doesn't seem to  
output any sound though.

OK, so now I've tried it on a different machine, a G5 with a fresh Max install (the other two were Intel iMacs).

At first I couldn't reproduce the crash with the test patch. Then after copying all the necessary 3rd party stuff needed to try the 'full' version - graphics, samples, objects, abstractions - to Max's search path (into a folder /Cycling74/3rd party), the crash started to reappear.

The difference this time is that the crash is not quite so fatal - Max is left producing a buzzing sound, but the dac~ can be turned off - on the other machines, once the beachball appeared, Max was totally unresponsive. CPU use rockets to > 110% and stays there. Turning the dac back on still produces the buzzing, but Max responds to key clicks in between bouts of beachball. I can even close the patch and reload it, but the buzzing persists as soon as you turn the dac on.

Attached is another process sample from Activity Monitor, taken whilst Max is buzzing & spinning,

OK, so now I've tried it on a different machine, a G5 with a fresh Max install (the other two were Intel iMacs).
 At first I couldn't reproduce the crash with the test patch. Then after copying all the necessary 3rd party stuff needed to try the 'full' version - graphics, samples, objects, abstractions - to Max's search path (into a folder /Cycling74/3rd party), the crash started to reappear.
 The difference this time is that the crash is not quite so fatal -   Max is left producing a buzzing sound, but the dac~ can be turned off - on the other machines, once the beachball appeared, Max was totally unresponsive. CPU use rockets to > 110%  and stays there. Turning the dac back on still produces the buzzing, but Max responds to key clicks in between bouts of beachball. I can even close the patch and reload it, but the buzzing persists as soon as you turn the dac on.
Attached is another process sample from Activity Monitor, taken whilst Max is buzzing & spinning,
cheers
Roger


maybe take the space out of the name "3rd party"

a wildly simplistic suggestion,
maybe take the space out of the name "3rd party"

I wasn't aware that Max ever had a problem with spaces in the file path, though now i look at it, Cycling seem to avoid using them in their folder names at least.

I tried replacing any spaces with hyphens anyway, but sadly that ol' ball just keeps on spinning. Maybe I'll just stay with Max 4.6 for this one,

I wasn't aware that Max ever had a problem with spaces in the file path, though now i look at it, Cycling seem to avoid using them in their folder names at least.
 I tried replacing any spaces with hyphens anyway, but sadly that ol' ball just keeps on spinning. Maybe I'll just stay with Max 4.6 for this one,
cheers
Roger


On 4 juin 08, at 11:22, roger.carruthers wrote:

> I wasn't aware that Max ever had a problem with spaces in the file 

> path, though now i look at it, Cycling seem to avoid using them in 

> I tried replacing any spaces with hyphens anyway, but sadly that ol' 

> ball just keeps on spinning. Maybe I'll just stay with Max 4.6 for 

There's no problem with spaces in the file names that I'm aware of. I 

would recommend that you strip your 3d party folder because it really 

> I wasn't aware that Max ever had a problem with spaces in the file  
> path, though now i look at it, Cycling seem to avoid using them in  
> their folder names at least.
> I tried replacing any spaces with hyphens anyway, but sadly that ol'  
> ball just keeps on spinning. Maybe I'll just stay with Max 4.6 for  
> this one,

There's no problem with spaces in the file names that I'm aware of. I  
would recommend that you strip your 3d party folder because it really  
seems to be the problem.

Zigzag~ was indeed the problem; replacing every instance with line~ allows the patch to run.

I guess I should call this a bug report, as the results were pretty terminal, and I could reproduce it on three different machines. Problem is, no-one else appears to have been able to reproduce it.

I will continue to try to narrow it down. I've searched for anything else called zigzag~ in the search path etc. 

FWIW, I've reduced the patch down further, and the following will crash for me every time if I use zigzag~ : with line~ there's no problem,

 Zigzag~ was indeed the problem; replacing every instance with line~ allows the patch to run.

I guess I should call this a bug report, as the results were pretty terminal, and I could reproduce it on three different machines. Problem is, no-one else appears to have been able to reproduce it.
 I will continue to try to narrow it down. I've searched for anything else called zigzag~ in the search path etc. 
 FWIW, I've reduced the patch down further, and the following will crash for me every time if I use zigzag~ : with line~ there's no problem,
cheers
Roger

that's good you found a solution. you should also take emmanuel's advice and rebuild your externals folder one object at a time to see if there's anything else in there causing problems.

FWIW, I can reproduce it when I'm using my custom searchpaths, but it 

runs fine with factory only. Guess I've got some cleaning up to do as 

On Jun 4, 2008, at 10:57, roger.carruthers wrote:

> Zigzag~ was indeed the problem; replacing every instance with line~ 

> I guess I should call this a bug report, as the results were pretty 

> terminal, and I could reproduce it on three different machines. 

> Problem is, no-one else appears to have been able to reproduce it.

> I will continue to try to narrow it down. I've searched for anything 

> else called zigzag~ in the search path etc.

> FWIW, I've reduced the patch down further, and the following will 

> crash for me every time if I use zigzag~ : with line~ there's no 

FWIW, I can reproduce it when I'm using my custom searchpaths, but it  
runs fine with factory only.  Guess I've got some cleaning up to do as  
well....

>
> I have an answer, of sorts:
>
> Zigzag~ was indeed the problem; replacing every instance with line~  
> allows the patch to run.
>
> I guess I should call this a bug report, as the results were pretty  
> terminal, and I could reproduce it on three different machines.  
> Problem is, no-one else appears to have been able to reproduce it.
> I will continue to try to narrow it down. I've searched for anything  
> else called zigzag~ in the search path etc.
> FWIW, I've reduced the patch down further, and the following will  
> crash for me every time if I use zigzag~ : with line~ there's no  
> problem,
> cheers
> Roger


it's giving me the pizza with a clean install if I leave it running for a bit.

Thanks very much for isolating this for us. I can reproduce here and we're gonna look into finding a fix. One interesting thing is that turning on Overdrive and Scheduler in Audio Interrupt prevents the crash from occurring. This may explain why some people can reproduce and others not.

Thanks for the clear example patch and for your persistence in bringing this to our attention.

Hi Roger,
Thanks very much for isolating this for us.  I can reproduce here and we're gonna look into finding a fix.  One interesting thing is that turning on Overdrive and Scheduler in Audio Interrupt prevents the crash from occurring.  This may explain why some people can reproduce and others not. 

> Zigzag~ was indeed the problem; replacing every instance with line~ allows the patch to run.

> I guess I should call this a bug report, as the results were pretty terminal, and I could reproduce it on three different machines. Problem is, no-one else appears to have been able to reproduce it.

> I will continue to try to narrow it down. I've searched for anything else called zigzag~ in the search path etc. 

> FWIW, I've reduced the patch down further, and the following will crash for me every time if I use zigzag~ : with line~ there's no problem,

And I also have quite a lot of 3rd party in my search path...

roger.carruthers wrote:
> I have an answer, of sorts:
>
>  Zigzag~ was indeed the problem; replacing every instance with line~ allows the patch to run.
>
> I guess I should call this a bug report, as the results were pretty terminal, and I could reproduce it on three different machines. Problem is, no-one else appears to have been able to reproduce it.
>  I will continue to try to narrow it down. I've searched for anything else called zigzag~ in the search path etc. 
>  FWIW, I've reduced the patch down further, and the following will crash for me every time if I use zigzag~ : with line~ there's no problem,
>

Hi Roger.
This patch is running fine here.
(5.02, OSX10.4.11)
And I also have quite a lot of 3rd party in my search path...

ooops, I missed some of this thread, sorry for the waste...

Spinning beachball crash