cebec

On my 3.2 GHz Pentium 4 XP SP2a system and my 2 GHz Core2Duo OS X 10.5.2 MacBook, alt-click-drag and aligning multiple cables takes somewhere around 5 minutes. It's just an estimate. It's long enough for me to get a cup of coffee and go to the bathroom and still have to wait.

On the MacBook, selecting a large number of objects and moving them around is a very slow and inaccurate affair. Has anyone else experienced these sorts of performance issues?

On my 3.2 GHz Pentium 4 XP SP2a system and my 2 GHz Core2Duo OS X 10.5.2 MacBook, alt-click-drag and aligning multiple cables takes somewhere around 5 minutes. It's just an estimate. It's long enough for me to get a cup of coffee and go to the bathroom and still have to wait.
On the MacBook, selecting a large number of objects and moving them around is a very slow and inaccurate affair. Has anyone else experienced these sorts of performance issues?
I'm running 5.02.


max-5-performance

Yes, same thing here. Not as bad as that, but a far, far cry from "snappy." ;-)

Mac OS X 10.5.2
MaxMSP 5.0.2 
8-core Mac Pro 2.8 GHz
16 GB RAM
Apogee duet


I was having really bad performance last night (and lately) on bigger patches. At first I thought it was because I had a folder with a lot of audio files in my max paths. I took that out, restarted max, it started faster, but the patch is slow to work with.

I closed that slow patch, and made a new one, and it was still slow until I restarted max.

I was having really bad performance last night (and lately) on bigger patches.  At first I thought it was because I had a folder with a lot of audio files in my max paths.  I took that out, restarted max, it started faster, but the patch is slow to work with.  

sometimes if I select more then 3 cables and do auto align, it will hang for a minute and crash. Often if I select more then one cable it takes upwards of a minute.

sometimes if I select more then 3 cables and do auto align, it will hang for a minute and crash.  Often if I select more then one cable it takes upwards of a minute.


Aligning of patch cords usually is very quick but it is using an AI algorithm to try to find a good path from the source outlet to the target inlet. In some cases it is challenging to find a good path. If you have specific examples where it performs badly (or even crashes) that can help future optimization (and fix) efforts.

Feel free to send to the list or directly to support at cycling74.

Aligning of patch cords usually is very quick but it is using an AI algorithm to try to find a good path from the source outlet to the target inlet.  In some cases it is challenging to find a good path.  If you have specific examples where it performs badly (or even crashes) that can help future optimization (and fix) efforts.

Also, another little tiny side thing, I dont know if I would call it a bug exactly, but irritating none the less. When I have an object selected and then click on a patch cable it keeps the object selected as if I had shift clicked the patch cable, often this happens when I am deleting a cable and I end up deleting an object as well. Mostly this has happened with bpatchers.

Also, another little tiny side thing, I dont know if I would call it a bug exactly, but irritating none the less.  When I have an object selected and then click on a patch cable it keeps the object selected as if I had shift clicked the patch cable, often this happens when I am deleting a cable and I end up deleting an object as well.  Mostly this has happened with bpatchers.


>Also, another little tiny side thing, I dont know if I would call >it a bug exactly, but irritating none the less. When I have an >object selected and then click on a patch cable it keeps the object >selected as if I had shift clicked the patch cable, often this >happens when I am deleting a cable and I end up deleting an object >as well. Mostly this has happened with bpatchers.

I'd call it a bug. For now try to click on a part of a patch cord that is not above an object. This will probably be fixed for the next incremental update.

I'd call it a bug.  For now try to click on a part of a patch cord that is not above an object. This will probably be fixed for the next incremental update.

Quote: Axiom-Crux wrote on Wed, 21 May 2008 16:36

----------------------------------------------------

> Also, another little tiny side thing, I dont know if I would call it a bug exactly, but irritating none the less. When I have an object selected and then click on a patch cable it keeps the object selected as if I had shift clicked the patch cable, often this happens when I am deleting a cable and I end up deleting an object as well. Mostly this has happened with bpatchers.

I had some similar issues where I think I'm deleting one thing, but I delete something else (almost like the computer is a click behind me). I also have similar GUI issues in Maya on OSX (but never on Windows). It feels like an OSX openGL deficiency or bug in the OS where windows act up, menus disappear, etc. Alias uses this tool kit in case you're wondering.

So I have to wonder if the GUI anomolies are an OSX thing.

Are any Windows users experiencing similar GUI issues (in addition to sluggish behavior in large patches)?

Quote: Axiom-Crux wrote on Wed, 21 May 2008 16:36
----------------------------------------------------
> Ill try and make you one.
>
> Also, another little tiny side thing, I dont know if I would call it a bug exactly, but irritating none the less.  When I have an object selected and then click on a patch cable it keeps the object selected as if I had shift clicked the patch cable, often this happens when I am deleting a cable and I end up deleting an object as well.  Mostly this has happened with bpatchers.
----------------------------------------------------

I had some similar issues where I think I'm deleting one thing, but I delete something else (almost like the computer is a click behind me).  I also have similar GUI issues in Maya on OSX (but never on Windows).  It feels like an OSX openGL deficiency or bug in the OS where windows act up, menus disappear, etc.  Alias uses this tool kit in case you're wondering.
http://www.tomsawyer.com/

Are any Windows users experiencing similar GUI issues (in addition to sluggish behavior in large patches)?


May or may not be relevant...in some cases, I've found performance can be slowed by having the inspector window open. In particular if you have a umenu with lots of items (mine has about 1200), and the inspector is open, everytime I select that menu, things get a bit slow. So, it could be related to the inspector, trying to figure out what you have selected...

May or may not be relevant...in some cases, I've found performance can be slowed by having the inspector window open.  In particular if you have a umenu with lots of items (mine has about 1200), and the inspector is open, everytime I select that menu, things get a bit slow.  So, it could be related to the inspector, trying to figure out what you have selected...

Has anyone had any success in controlling filtergraph~ settings inside a

I've been trying to get autopattr to do this but it doesn't seem to have any

effect (number boxes in same patch work fine)

Has anyone had any success in controlling filtergraph~ settings inside a
bpatcher in Max 4.6.3 ?

I've been trying to get autopattr to do this but it doesn't seem to have any
effect (number boxes in same patch work fine)

> Aligning of patch cords usually is very quick but it is using an AI

> algorithm to try to find a good path from the source outlet to the

> target inlet. In some cases it is challenging to find a good path.

> If you have specific examples where it performs badly (or even

> crashes) that can help future optimization (and fix) efforts.

Sometimes I wish a less intelligent path. For me a good path has as few 

corners as possible. That is exactly two if the order of connection is 

top down, and exactly 4 if its bottom up...

I know its a matter of taste, but in my experience, the path is less 

reliable "a good one" as it was in Max 4.x. And in Max 4, all I had to 

do to correct, is move the existing cord by hand. In Max 5 i have to 

redo the whole segmentation by hand again...

A preference for "simplified segmentation" would be great...

It seems that AI algorithm takes also other cords into account. I'd skip 

I have to add, that I do respect and even admire all AI attempts - and 

the algorithm has its own beauty, but doesn't fit my personal taste in 

Rob Sussman schrieb:
> Aligning of patch cords usually is very quick but it is using an AI
> algorithm to try to find a good path from the source outlet to the
> target inlet.  In some cases it is challenging to find a good path.
> If you have specific examples where it performs badly (or even
> crashes) that can help future optimization (and fix) efforts.

Sometimes I wish a less intelligent path. For me a good path has as few 
corners as possible. That is exactly two if the order of connection is 
top down, and exactly 4 if its bottom up...
I know its a matter of taste, but in my experience, the path is less 
reliable "a good one" as it was in Max 4.x. And in Max 4, all I had to 
do to correct, is move the existing cord by hand. In Max 5 i have to 
redo the whole segmentation by hand again...

It seems that AI algorithm takes also other cords into account. I'd skip 
that...

I have to add, that I do respect and even admire all AI attempts - and 
the algorithm has its own beauty, but doesn't fit my personal taste in 
terms of the result...

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


Another performance issue I ran into with Max 5 is when duplicating objects. In one patch it was taking a good 4 or 5 seconds to duplicate an object. Sometimes the spinny/hourglass appeared. I was trying to make a grid of 20 of them and I had to wait for the object to appear before hitting command+D again. It took well over a minute to make my grid.

I went back to Max 4 to compare and it duplicated the same objects in an unnoticeable split second. I hit command+D quickly 20 times and was done in a couple seconds.

I don't remember exactly what I was duplicating. The basic objects are quick to duplicate in Max 5. I think this was a bpatcher. Maybe even a bpatcher with a bpatcher inside it. I can post more details next time I run into it.

BTW: 2.33 GHz Core2Duo OS X 10.5.2 MacBook

Another performance issue I ran into with Max 5 is when duplicating objects. In one patch it was taking a good 4 or 5 seconds to duplicate an object. Sometimes the spinny/hourglass appeared. I was trying to make a grid of 20 of them and I had to wait for the object to appear before hitting command+D again. It took well over a minute to make my grid. 

BTW: 2.33 GHz Core2Duo OS X 10.5.2 MacBook


Quote: Adam Murray wrote on Thu, 22 May 2008 12:23

> Another performance issue I ran into with Max 5 is when duplicating objects.

> I went back to Max 4 to compare and it duplicated the same objects in an unnoticeable split second.

I wonder if this has to do with the new Undo capability of Max 5. I notice that there is no option to limit the number of "undos". Perhaps the longer the program runs, the longer this file becomes, and the longer it takes to update.

Quote: Adam Murray wrote on Thu, 22 May 2008 12:23
----------------------------------------------------
> Another performance issue I ran into with Max 5 is when duplicating objects. 

> I went back to Max 4 to compare and it duplicated the same objects in an unnoticeable split second. 

Quote: arne wrote on Thu, 22 May 2008 12:51

> I wonder if this has to do with the new Undo capability of Max 5. I notice that there is no option to limit the number of "undos". Perhaps the longer the program runs, the longer this file becomes, and the longer it takes to update.

I bet this is what's causing the problems. If so, a preference for maximum undos could fix a lot of this. Max doesn't start off with slow performance for me, only after working for a while. The patch I'm working with lately seems to start slowing down after I work in the subpatches for a while.

And one more "unsegment all" cables vote for me. :)

Quote: arne wrote on Thu, 22 May 2008 12:51
----------------------------------------------------
>
> I wonder if this has to do with the new Undo capability of Max 5. I notice that there is no option to limit the number of "undos". Perhaps the longer the program runs, the longer this file becomes, and the longer it takes to update.
>
> Just a guess.
----------------------------------------------------

I bet this is what's causing the problems.  If so, a preference for  maximum undos could fix a lot of this.  Max doesn't start off with slow performance for me, only after working for a while.  The patch I'm working with lately seems to start slowing down after I work in the subpatches for a while.

And one more "unsegment all" cables vote for me.  :)


I appreciate the guess about how multiple undo works, but it's almost certainly unrelated to any specific performance issue involved in duplicating an object. Performance issues happen because in general, software is initially written to work correctly, not to perform as fast as possible. Then, it is tested and once specific cases of poor performance are discovered, it is profiled and optimized. We can only optimize things that we can reproduce as performance problems. We don't try to speculate about what might be useful to optimize before we know whether it is really worth the effort. So, we welcome any examples.

There are things that are just inherently slower when you use a compositing anti-aliased user interface, such as moving large numbers of objects.

I appreciate the guess about how multiple undo works, but it's almost certainly unrelated to any specific performance issue involved in duplicating an object. Performance issues happen because in general, software is initially written to work correctly, not to perform as fast as possible. Then, it is tested and once specific cases of poor performance are discovered, it is profiled and optimized. We can only optimize things that we can reproduce as performance problems. We don't try to speculate about what might be useful to optimize before we know whether it is really worth the effort. So, we welcome any examples. 

There are things that are just inherently slower when you use a compositing anti-aliased user interface, such as moving large numbers of objects. 

Quote: David Zicarelli wrote on Thu, 22 May 2008 14:44

> There are things that are just inherently slower when you use a compositing anti-aliased user interface, such as moving large numbers of objects.

My guess was based upon the fact that these performance issues start to occur after using the program for a while (i.e. after several hours of coding).

The same action (duplicating/moving) a large number of objects works fine right after restarting Max 5. As such, it is difficult to document (and not that difficult to work around).

By the way, does anyone else find it incredible that David Z. is directly monitoring these forums? What other software can claim this kind of interest in user satisfaction?

Quote: David Zicarelli wrote on Thu, 22 May 2008 14:44
----------------------------------------------------
> So, we welcome any examples. 

> There are things that are just inherently slower when you use a compositing anti-aliased user interface, such as moving large numbers of objects. 

By the way, does anyone else find it incredible that David Z. is directly monitoring these forums? What other software can claim this kind of interest in user satisfaction?


Quote: arne wrote on Thu, 22 May 2008 15:07

---------------------------------------------------- 

> My guess was based upon the fact that these performance issues start to occur after using the program for a while (i.e. after several hours of coding).

> The same action (duplicating/moving) a large number of objects works fine right after restarting Max 5.

I have encountered this too, and that's why I tried restarting Max when I ran into the slow duplication issue I described above. It didn't help in this case, which is why I mentioned it. I think there is a specific issue with copying bpatchers and/or deeply nested patches. I will try to investigate more and post an example at some point.

Quote: arne wrote on Thu, 22 May 2008 15:07
---------------------------------------------------- 
> My guess was based upon the fact that these performance issues start to occur after using the program for a while (i.e. after several hours of coding).
>
> The same action (duplicating/moving) a large number of objects works fine right after restarting Max 5. 

I have encountered this too, and that's why I tried restarting Max when I ran into the slow duplication issue I described above. It didn't help in this case, which is why I mentioned it. I think there is a specific issue with copying bpatchers and/or deeply nested patches. I will try to investigate more and post an example at some point.


Same here. It's fine, but after a couple hours I notice it's slowing down. I'll try to see and remember to write down exactly what I did next time I notice.

> The same action (duplicating/moving) a large number of objects works fine right after restarting Max 5. As such, it is difficult to document (and not that difficult to work around).

Same here. The best workaround so far has been restarting Max, which works pretty well.

> By the way, does anyone else find it incredible that David Z. is directly monitoring these forums? What other software can claim this kind of interest in user satisfaction?

The only other software the programmers themselves interacted with the users I ever used was Electric Image back when Mark Granger and Matt Hoffmann used to show up at the monthly user meetings (this was before the web, and back when I had a 14400 modem). I think David and the other cycling programmers attention to this forum is unprecedented for software of this level. Cycling has some of the best support for any software on any platform to me. And the users kick ass too.

Quote: arne wrote on Thu, 22 May 2008 15:07
----------------------------------------------------
> My guess was based upon the fact that these performance issues start to occur after using the program for a while (i.e. after several hours of coding).
>

Same here.  It's fine, but after a couple hours I notice it's slowing down.  I'll try to see and remember to write down exactly what I did next time I notice.

Same here.  The best workaround so far has been restarting Max, which works pretty well.

> By the way, does anyone else find it incredible that David Z. is directly monitoring these forums? What other software can claim this kind of interest in user satisfaction? 

The only other software the programmers themselves interacted with the users I ever used was Electric Image back when Mark Granger and Matt Hoffmann used to show up at the monthly user meetings (this was before the web, and back when I had a 14400 modem).  I think David and the other cycling programmers attention to this forum is unprecedented for software of this level.  Cycling has some of the best support for any software on any platform to me.  And the users kick ass too.


Are you working on the same patch for a couple of hours? What if you close the patch and open it again?

If I had to guess it could be a slow memory leak which after a couple of hours accumulates enough so that things start to slow down. We could put some memory usage counters in place that might help reveal whether this theory is correct.

Are you working on the same patch for a couple of hours? What if you close the patch and open it again? 

Quote: David Zicarelli wrote on Thu, 22 May 2008 20:20

> Are you working on the same patch for a couple of hours? What if you close the patch and open it again?

Everything runs pretty good when Max is started fresh, after a few hours of patching everything slows down. If I keep patching after it's slowed down, eventually I crash. Would the crash reports be useful if I can get Max to crash this way? I'll try to keep more attention of how and when things slow down.

> If I had to guess it could be a slow memory leak which after a couple of hours accumulates enough so that things start to slow down. We could put some memory usage counters in place that might help reveal whether this theory is correct.

I haven't been watching Max's memory usage, I'll start doing that when I patch now. It kinda reminds me of being on OS 7.5 again. :)

4.6.3 is definately way faster in some ways.

5.0.2's been pretty solid except for the slowing down. I think I may have had the inspector window open most the time, I'll try closing that too.

Quote: David Zicarelli wrote on Thu, 22 May 2008 20:20
----------------------------------------------------
> Are you working on the same patch for a couple of hours? What if you close the patch and open it again? 

Everything runs pretty good when Max is started fresh, after a few hours of patching everything slows down.  If I keep patching after it's slowed down, eventually I crash.  Would the crash reports be useful if I can get Max to crash this way?  I'll try to keep more attention of how and when things slow down.  

> If I had to guess it could be a slow memory leak which after a couple of hours accumulates enough so that things start to slow down. We could put some memory usage counters in place that might help reveal whether this theory is correct.
>
> David Z.
>

I haven't been watching Max's memory usage, I'll start doing that when I patch now.  It kinda reminds me of being on OS 7.5 again. :)

5.0.2's been pretty solid except for the slowing down.  I think I may have had the inspector window open most the time, I'll try closing that too.


> Are you working on the same patch for a couple of hours?

> What if you close the patch and open it again?

> If I had to guess it could be a slow memory leak which after a couple of hours accumulates enough so that things start to slow down.

I have noticed that memory usage has increased (via MenuMeters, an OSX utility) over time, sometimes dramatically - from about 20% to over 50% (4 GB of RAM). over the course of several days.

Quote: David Zicarelli wrote on Thu, 22 May 2008 20:20
----------------------------------------------------
> Are you working on the same patch for a couple of hours? 

> What if you close the patch and open it again? 

> If I had to guess it could be a slow memory leak which after a couple of hours accumulates enough so that things start to slow down. 

I have noticed that memory usage has increased (via MenuMeters, an OSX utility) over time, sometimes dramatically - from about 20% to over 50% (4 GB of RAM). over the course of several days.


That's one more reason for me to migrate to version 5

Last night I was working with copying/duplicating subpatchers when Max slowed down after about 30 minutes of use.

Memory use went from 231 megs with nothing open, Max just started up, to 270 megs with nothing open in Max (after working with a few patches). Everything seemed to slow down after I had been copying and working with subpatches.

One weird thing that happened was that when I was working on a version of the patch with abstractions instead of subpatches, it didn't really slow down, but the abstractions stopped opening after a point. double clicking did nothing. newly made copies of the same exact abstractions worked and opened up as usual.

Eventually, Max did crash, after slowing down a lot. Even with no windows open and a new patch (after closing everything I was working on), hitting n for a new object took a few seconds. everything slowed down, this was when memory use was around 270 for Max with nothing open. Somewhere Max needed 40 more megs or ram to just run from when I started Max fresh.

Memory use went from 231 megs with nothing open, Max just started up, to 270 megs with nothing open in Max (after working with a few patches).  Everything seemed to slow down after I had been copying and working with subpatches.

One weird thing that happened was that when I was working on a version of the patch with abstractions instead of subpatches, it didn't really slow down, but the abstractions stopped opening after a point.  double clicking did nothing.  newly made copies of the same exact abstractions worked and opened up as usual.

Eventually, Max did crash, after slowing down a lot.  Even with no windows open and a new patch (after closing everything I was working on), hitting n for a new object took a few seconds.  everything slowed down, this was when memory use was around 270 for Max with nothing open.  Somewhere Max needed 40 more megs or ram to just run from when I started Max fresh.

Do you have patches and files which can make this happen?

Quote: Andrew Pask wrote on Tue, 27 May 2008 10:00

> Do you have patches and files which can make this happen?

I haven't been able to repeat these crashes. They just happen after about an hour or working in Max5. Usually after copying and pasting subpatches. I can sort of feel when it starts to feel like it may crash. Things slow down, abstractions stop working, and then Max may or may not crash. I wish I could nail it down to something in particular.

Quote: Andrew Pask wrote on Tue, 27 May 2008 10:00
----------------------------------------------------
>
>
> Is this crash repeatable?
>
> Do you have patches and files which can make this happen?
>
> If so - please send them into support.
>
> Cheers
>
>
> Andrew
----------------------------------------------------

I haven't been able to repeat these crashes.  They just happen after about an hour or working in Max5.  Usually after copying and pasting subpatches.  I can sort of feel when it starts to feel like it may crash.  Things slow down, abstractions stop working, and then Max may or may not crash.  I wish I could nail it down to something in particular.


I'm also experiencing random crashes on my MacBook with OS X 10.5.2 and now 10.5.3. I can't reproduce the exact conditions and they seem to occur 'randomly'.

I will report back with any findings but for now, I am needing to save regularly just in case. Perhaps an auto-save feature would be useful to have as an option!

I'm also experiencing random crashes on my MacBook with OS X 10.5.2 and now 10.5.3. I can't reproduce the exact conditions and they seem to occur 'randomly'. 

I will report back with any findings but for now, I am needing to save regularly just in case. Perhaps an auto-save feature would be useful to have as an option!


Max 5 on my XP and OS X machines takes an excessively long time to start.

It might be useful (to me) if a highlighted line or object, etc. on one 'view' could be mirrored in other views. Is this feasible, desirable, computationally expensive?

Max 5 on my XP and OS X machines takes an excessively long time to start. 

It might be useful (to me) if a highlighted line or object, etc. on one 'view' could be mirrored in other views. Is this feasible, desirable, computationally expensive?


for now I am happily working on stable, readable, snappy 4.6.3.

although I like all the new features in 5, and don't mind the look, I can't help but feel that it is not a mature and dependable tool like 4.6.3 is, yet. the readability/blurriness thing doesn't help...

i've decided to stick with 4 for a while more - just got tired of being distracted by the little "rough edges" that inevitably come with such a major update. eventually I will switch, of course. maybe around 5.1?

although I like all the new features in 5, and don't mind the look,  I can't help but feel that it is not a mature and dependable tool like 4.6.3 is, yet. the readability/blurriness thing doesn't help...

Max 5 performance