Th8a

Hello, most helpful MAX community. I'm getting towards the end of building a massively large patch that I intend to use as a standalone app. I have 127 instances of a rather large sub-patch that occurs in the patch's structure, and i was double sure to include absolutely no UI elements within that sub-patch, as i am aware of what the re-draw tax would be for such a thing... So I made one master UI that controls all 127 of the sub-patches based on which number you have selected to assign parameters to. So far, the UI is pretty light and everything is working perfectly except for two major problems: 1 the patch start-up time is somewhere around 4 mins... and once it starts, the MIDI behaves properly, but all other functions (UI etc.) are laggy, slow, choppy and delayed in response. I tried going through and distributing defer and deferlow objects to hopefully allow more important elements to be responsive, but this actually made the problem far worse, so i went ahead and deleted all of those.

Furthermore, The very same patch was running relatively smoothly under OSX 10.8.5. on a hackintosh. Since I recently upgraded to 10.9.5, I started reeaaaallly noticing the problem BAD. Adjusting the scheduler parameters is only so helpful.

Are there any tips out there on how to improve the overall performance of a patch, or known causes for slow performance on osx Mavericks?

I would post the patch, but it's HUGE, and honestly, im a little guarded about the idea of what the patch does until i actually finish it! I suppose i am only asking for general guidelines for patch performance anyway... lol, sorry bout that, but here's my specs:

Many thanks to anyone who responds to this, and to everyone who posts and responds in this forum at all!

Hello, most helpful MAX community. I'm getting towards the end of building a massively large patch that I  intend to use as a standalone app. I have 127 instances of a rather large sub-patch that occurs in the patch's structure, and i was double sure to include absolutely no UI elements within that sub-patch, as i am aware of what the re-draw tax would be for such a thing...  So I made one master UI that controls all 127 of the sub-patches based on which number you have selected to assign parameters to. So far, the UI is pretty light and everything is working perfectly except for two major problems: 1 the patch start-up time is somewhere around 4 mins... and once it starts, the MIDI behaves properly, but all other functions (UI etc.) are laggy, slow, choppy and delayed in response. I tried going through and distributing defer and deferlow objects to hopefully allow more important elements to be responsive, but this actually made the problem far worse, so i went ahead and deleted all of those. 

Furthermore, The very same patch was running relatively smoothly under OSX 10.8.5. on a hackintosh. Since I recently upgraded to 10.9.5, I started reeaaaallly noticing the problem BAD. Adjusting the scheduler parameters is only so helpful. 

Are there any tips out there on how to improve the overall performance of a patch, or known causes for slow performance on osx Mavericks? 

I would post the patch, but it's HUGE, and honestly, im a little guarded about the idea of  what the patch does until i actually finish it! I suppose i am only asking for general guidelines for patch performance anyway... lol, sorry bout that, but here's my specs:

Intel i5 3.1GHz x4
8 GB 1600 MHz DDR3
NVIDIA GeForce GT 440

max7-running-waaayyyy-too-slow-on-all-fronts

Without an example its impossible to help. You could be using more than one metro, do's it use openGL, a lot of matrices , etc etc ??

Too many unknown variables to give any help.

I'd check the forums for optimisation topics.

Without an example its impossible to help. You could be using more than one metro, do's it use openGL, a lot of matrices , etc etc ??
Too many unknown variables to give any help.
I'd check the forums for optimisation topics.


127 instances... I suppose you're *not* using poly~? Because I'm fairly certain that'd help you greatly.

And yeah, it's waaayyyy too difficult to give much advice other than platitudes. Oh, except one piece of anecdotal evidence: I had a major slowdown in a patch recently. Turns out, it was a udpsend set somewhere sending OSC to the wrong ip addresses on a local network. Turned those off and everything started running smoothly again.

poly~ might be great, at least when you do not need the 127 voices all the time. so you would e.g. start up ith 16 voices turned on, and then the user can raise this number.

like others said, it would be better to see the subpatch in question.

and doublecheck if you forgot some settings in your new system, it is a bit suspicious that it had been working so much better in 10.8 before.

MAX7 running waaayyyy too slow on all fronts