Philippe OLLIVIER

While working on an audio patch, I was afraid by the CPU consomption in Max 6.

In Max 5 it was 8% at 512/512 and now it is 17/18% with Max 6 at the same IO and Signal vector Size.

In Max 5 at 256/256 the CPU consomption is 1%.

In Max 6, at the same Vector Size the consomption is 3%.

A patch with 10 [pfft~ gizmo_loadme 4096 4]

So, it is the same or a little better for pfft~, but for objects we often use, the CPU consomption is increased (from 1 to 3) in my case.

Is it a bug or is something that cannot be improved?

Hi,
While working on an audio patch, I was afraid by the CPU consomption in Max 6.
In Max 5 it was 8% at 512/512 and now it is 17/18% with Max 6 at the same IO and Signal vector Size.

So I decided to make 2 tests :
I made a patch containing 76 [*~].
In Max 5 at 256/256 the CPU consomption is 1%.
In Max 6, at the same Vector Size the consomption is 3%.

Second test :
A patch with 10 [pfft~ gizmo_loadme 4096 4]
In max 5 - 256/256 the CPU is 16/17%
In Max 6 - 256/256 the CPU is 16%

Is it the case for everybody?
Is it a bug or is something that cannot be improved?
Below are the patches.

msp-performances-in-maxmsp-6

OS X.6.8
CPU : 2.8 Ghz Intel Core 2 Duo
Philipe.


1. 76 [*~]
   max5 => 0%-1%
   max6 => 1%-2%
2. 10 [pfft~]
   max5 => 10%-13%
   max6 => 8%-12%

i'm having the same problem with my patches. My main patch which takes up 30% cpu in Max5 yet it takes up to 60%-100% cpu in Max6, rendering my patch useless in Max6!

i was hoping this problem was just me overlooking something simple since i'm so excited for Max6, but now i see i'm not alone.

What can we do (besides not upgrade, since i do think Max6 sounds better, at least with those working example patches it does)?

i'm having the same problem with my patches.  My main patch which takes up 30% cpu in Max5 yet it takes up to 60%-100% cpu in Max6, rendering my patch useless in Max6!

i'm rocking
OSX vers. 10.6.8
2.66hz intel core 2 duo
4gb memory

i was hoping this problem was just me overlooking something simple since i'm so excited for Max6, but now i see i'm not alone.   

What can we do (besides not upgrade, since i do think Max6 sounds better, at least with those working example patches it does)?


The first thing I've tried is to load some of my usual patches to see if all works. All is fine, so far, except CPU is around 2 or 3 times higher than in Max5. I hope it's due to beta and that's not the price of the improvement in the quality of Max

The 64 bit signals will definitely consume more CPU cycles, but the apparent performance hit does seem a bit heavy.

I dearly hope that the beta is a slow debug build, otherwise I will most definitely not be upgrading. I recently bought a top of the line MBP to run Max 5, and now patches that used to top out at 30-40% CPU are crackling in Max 6. I could increase my latency something horrid, but I don't see why I should have to. Before anybody blames my patching skills and accuses me of being "shit at programming", consider this:

The emergence of a set of "SSE optimised" externals for Max 5 indicates that Max 5 does NOT use SSE parallelism (a way of performing calculations on 2, 4, or even 8 pieces of data at a time using special CPU instructions - Intel's version of Altivec). SSE instructions have been around for a long time, and IMHO Max ought to make use of them. From the way things perform in Max 6 I can only assume that this has not changed (somebody please correct me if I'm wrong)!

BTW, there still an option for Altivec optimisation in the Audio settings window, even though Max 6 doesn't run on PPCs.

Given Max's high system demands I think it is now a fair assumption that anyone running Max 6 will definitely have a PC capable of SSE3 instructions. All Intel Macs support this instruction set. I would prefer to spend my money on improvements to years-old code, rather than pretty GUI updates. I find the wheel menu and the patch cord arrows just get in my way.

Using a program like Max requires a certain level of computer-literacy. You have to be a bit of a geek in the first place. The more time spent on making things noob-friendly, the less time spent on bringing the rest of the package up to speed. I don't care how user-friendly something is if it's bloated and sluggish.

Before the petrol bombs fly, I will say that the improvements to [poly~] regarding resampling are an absolute joy. This is something we've desperately needed for a long time. And, the filters sound better. I don't think I'll be using dictionaries much, but that's more because I approach things from a fairly low-level perspective. I can see their value.

But there are many things that seem trivial to implement but have been overlooked:

1. [groove~] has way improved sound quality but still cannot be triggered at audio rate. (How many threads have we seen about that!?!)

2. [play~] does not have improved interpolation. To all intents and purposes, [play~] IS [groove~] but without the internal counter or loop logic. Surely the new interpolation code in [groove~] could be re-used?

3. [phasor~] cannot be re-triggered by a signal.

Regarding [gen~], while I applaud the idea, I can't quite bring myself to love it unless the rest of Max 6 speeds up. Otherwise it feels like a way of making up for lost speed, albeit one that requires a slightly different approach to patching. Don't get me wrong, the [history] node in itself is going to make a lot of issues go away, but even with my meagre C skills I can write simple externals that run orders of magnitude faster than [gen~].

All persons portayed within this post are fictitious and any resemblance to persons living or dead is purely coincidental. The author accepts no responsiblity for any milk spillage, ego bruising, or kitty slaying that may occur as a result of reading. YMMV.

P.S. It's obvious that work has gone into improving performance of FFT algorithms, as well as many other areas. This is great. I don't want to give the impression that the developers haven't been working hard, and I would be the first one to admit that they are vastly more talented and capable than me. But I am dismayed that a number of core objects seem to suffer such a large performance hit. Progress = getting more things done. What good is it if you can patch things easier if the patch itself won't work anymore?

Interesting stuff, I'm not sure how many times I'd just use 76 *~ objects in my patches so I decided to make an audio 'voice' which contains:

I copied this voice 50 times. One version of the patch houses the voices in a Poly~ (with the addition of gate~) and the other does not. The idea being to approximate the kind of things you might get in an actual performance patch. And to look at how the use of poly~ and multithreading might affect the CPU performance.

I tested the patch in Max 4.6.3, Max 5.1.9, Max 6.0.0 beta.

Results on a MacBook Pro 2.66 Intel Core i7.

I/O vect 256, Sig vect 265, Overdrive On, Audio Interrupt On.

Not i'm not sure what the Activity Monitor readings actually mean - they jump high when poly~ is in parallel mode.

50 voices non Poly~
version    CPU% reported by Max         CPU% reported by Activity Monitor
Max 4.6    31-32%                       50%
Max 5.1    34-35%                       46%
Max 6.0    37 with spikes to 53%        56%

50 voices within Poly~
version    CPU% Max    (w/parallel)     CPU% Activity Monitor (w/parallel)
Max 4.6    32-34%      n/a              40.6%                 n/a
Max 5.1    35-36%      18-20%           48%                   75%
Max 6.0    39% sp 54%  21-23% sp 29%    58%                   87%

As you can see the parallel processing option for poly~ seems to really reduce (spread) the load. Another interesting thing is that the performance between 4.6 and 5.1 is greater in some instances than between 5.1 and 6. My only slight concern is that 6.0's CPU usage seemed to be quite spiky on my machine.

Obviously 6. is still a beta an I imagine they still have a few things to sort out so it's a bit early to make any definitive statements on performance. It seems to me that Max 6 offers a lot of new functionality and objects, the gap-less playback, filter design tools, faster JS and better editor, brilliant new jitter tools (materials, lighting, physics, etc). It seems that if you are prepared to optimise your patch using poly~ the performance hit for all these new things is not so bad.

Patches attached - don't forget to turn audio off/on when changing the parallel setting of poly~

line~
phasor~
*~
+~
play~
pfft~
svf~
amongst a few other things.

I tested the patch in Max 4.6.3, Max 5.1.9, Max 6.0.0 beta. 

Results on a MacBook Pro 2.66 Intel Core i7.
I/O vect 256, Sig vect 265, Overdrive On, Audio Interrupt On.
Not i'm not sure what the Activity Monitor readings actually mean - they jump high when poly~ is in parallel mode.

Obviously 6. is still a beta an I imagine they still have a few things to sort out so it's a bit early to make any definitive statements on performance. It seems to me that Max 6 offers a lot of new functionality and objects, the gap-less playback, filter design tools, faster JS and better editor, brilliant new jitter tools (materials, lighting, physics, etc). It seems that if you are prepared to optimise your patch using poly~ the performance hit for all these new things is not so bad.  

Patches attached - don't forget to turn audio off/on when changing the parallel setting of poly~


(Shouldn't this be posted in the beta forum? just sayin' :D )

"The 64 bit signals will definitely consume more CPU cycles, but the apparent performance hit does seem a bit heavy."

"even with my meagre C skills I can write simple externals that run orders of magnitude faster than [gen~]"

you can... so have you? run a performance test. even gen~ compared to a max 5 external you write, the results would probably be helpful to show here if you can. otherwise, even with my meager lack of social-convention, i've still got a 14-inch dick, too. baaahahahaha! sorry, couldn't resist. :)

"It seems that if you are prepared to optimise your patch using poly~ the performance hit for all these new things is not so bad. "

"1. [groove~] has way improved sound quality but still cannot be triggered at audio rate. (How many threads...

2. [play~] does not have improved interpolation..."

shouldn't we move on to the sample interpolation options within gen~ anyways?

stop using groove~ and play~ already? what's the matter with you?!

oh sorry, i got my panties in a wad because my kitty was chomping my leg while i was trying to slay it.

(only thing i write here in complete seriousness: this thread is a fun read. :)

shouldn't we move on to the sample interpolation options within gen~ anyways?
stop using groove~ and play~ already? what's the matter with you?!

(only thing i write here in complete seriousness: this thread is a fun read. :)


That's OK raja, my panties were knotted into a tight little ball :P

But I've been at a dinner gathering and I played with my friends' kitties (no, really), which has lightened me up a bit :)

I'm ironing out the bugs in a sinc-interpolating playback object ATM, and it should be on the share pages within the week. Currently my naive implementation consumes about 1% CPU per instance. Out of curiosity, I started patching together an equivalent in [gen~]. I hadn't even got half-way before the CPU meter was at 12%. Needless to say I gave up.

For 16-point interpolation you need more than 16 peeks, 16 multiplies, a frac or two, 16 adds, and then some, plus a bunch of other utility objects. For this sort of stuff it's not possible to get anything close to 'optimal machine code' out of [gen~] (but then I didn't think so in the first place). This is not to knock the new benefits though; [history] makes a lot of old headaches go away. Not everyone wants to write externals, so I see great things on the horizons for the more conventional Maxers.

Oh, and the new Jitter stuff IS badass, agreed. All I was saying about [play~] is that the same nice interpolation could be achieved with the smallest bit of copy n' pasting. It all comes down to my old sentiment that before we get new goodies, it would be nice to have existing functionality brought up to 'speed' with competing software. I mean, we've already paid a lot of money for what was once somebody else's codebase with a nicer GUI.

well, i do not see that anyone has investigated how the new preferences panel for controlling scheduler values (queue throttle, poll throttle, redraw queue throttle, event interval, enable/disable refresh, refresh rate, scheduler interval, scheduler slop) affects execution time.

we all know io-buffer size, but what about adjusting some of these?

Might well be different values are more appropriate for various max/msp/jitter applications.(throttle down redraw for better controller/synth work? whatever, needs examining)

just wanted to point out the new preferences...

oh, and strong parliamentary 2nd on the beta forum bit: this thread should really be moved. Beta software discussions shouldn't be mixed with published software discussions.

And, as far as many forum readers are concerned, *some* beta discussions should stay in beta forums!!: once software is released, go ahead state your judgement (once!) and act upon it, but it is really useless to beat the horse *after* the race.

well, i do not see that anyone has investigated how the new preferences panel for controlling scheduler values (queue throttle, poll throttle, redraw queue throttle, event interval, enable/disable refresh, refresh rate, scheduler interval, scheduler slop) affects execution time.
we all know io-buffer size, but what about adjusting some of these?
Might well be different values are more appropriate for various max/msp/jitter applications.(throttle down redraw for better controller/synth work?  whatever, needs examining)
just wanted to point out the new preferences...
oh, and strong parliamentary 2nd on the beta forum bit: this thread should really be moved. Beta software discussions shouldn't be mixed with published software discussions.
And, as far as many forum readers are concerned, *some* beta discussions should stay in beta forums!!: once software is released, go ahead state your judgement (once!) and act upon it, but it is really useless to beat the horse *after* the race.


"It all comes down to my old sentiment that before we get new goodies, it would be nice to have existing functionality brought up to 'speed' with competing software."

"Beta software discussions shouldn't be mixed with published software discussions."

(but ya, if people could follow the sticky instructing us to post in beta, that might make it easier for the devs to focus on them appropriately...)

That's segregation! :D
(but ya, if people could follow the sticky instructing us to post in beta, that might make it easier for the devs to focus on them appropriately...)


Could you send me some details about the machine you are testing on, and the 16-point interpolation gen~ patcher? I think we should be able to get very good performance for this from gen~, and if you're not, it may be a great example for us to use in our optimization testing.

See attached screenshot: this is more expensive than my whole external.

OK, my knickers are untwisted. FWIW, I got the CPU down a great deal, and here's a sinc interpolating playback [gen~] for y'all. I get ~6% CPU, which is aight but by no means great (not to diss [gen~], but this sort of thing is definitely much better in pure C). I reckon if [play~] had the same interpolation as [groove~], the CPU consumption would be negligible compared to this.

[edited for tidy patch cords and pretty colours]

[edited again for bugfix and added sine test]

I can't reproduce your experience here. I have replicated the patch, however, without any outlets (or side-effects) there is no actual signal processing being done in the generated machine code. According to the gen~ object it is using about 0.01% of available time, which is probably under measurement error. In the parent patcher, 0.4% CPU is being used, which captures the overhead cost of the gen~ container. Measuring performance in top, or activity monitor, shows a greater percentage, but this appears unchanged whether the gen~ object is present or not.

Could I ask you what OS version and the details (model, cpu) of your Mac, and how you measured the high CPU cost of the gen~ patcher? There certainly shouldn't be a high overhead of this nature for the patch you sent; if there is, this is a bug report.

Could I ask you what OS version and the details (model, cpu) of your Mac, and how you measured the high CPU cost of the gen~ patcher?  There certainly shouldn't be a high overhead of this nature for the patch you sent; if there is, this is a bug report.

Ah, sorry Graham. Please see the above post. I have no idea why my CPU meter was so high with that unfinished patch. If it helps, MBP 2.2GHz i7, 8GB RAM, Snow Leopard.

I guess I was writing my reply when you posted!

FWIW, with your new patcher, on my machine (MacBook Pro 2GHz Core i7, running 10.6.8) I'm getting about 0.5% from gen~ (according to the gen~ internal measurement), and around 2% for the parent patcher (according to the mixer engine measurement). The gen~ measurement goes up to about 0.8% if I drive the phasor~ at 100Hz.

There's no doubt that it hand-coded C can generally be tuned and optimized to have better performance than something which has been generated from a more generic system, but overall we've been quite pleased with the performance gen~ is producing. It's important that gen~ has good performance, on average significantly better than a comparable MSP patcher (of sufficient complexity), but performance is not the only motivation for Gen. Simply making available low level processing within an environment that doesn't require knowledge of pointer arithmetic is very important; it makes available to any user (regardless of their programming background) a whole range of processes that were previously impossible or impractical in MSP, especially regarding the [history] operator as you say. The ability to generate and test live without needing to stop the program and recompile is also very important to support exploratory and live programming, both of which are very important creative activities. To expose this kind of generality may imply trade-offs for performance, but overall I think Gen is handling that trade-off quite well.

By the way, the 12 point interpolator sounds great, would you mind if we modified it slightly and added it to the distribution examples?

I guess I was writing my reply when you posted! 

FWIW, with your new patcher, on my machine (MacBook Pro 2GHz Core i7, running 10.6.8) I'm getting about 0.5% from gen~ (according to the gen~ internal measurement), and around 2% for the parent patcher (according to the mixer engine measurement).  The gen~ measurement goes up to about 0.8% if I drive the phasor~ at 100Hz. 

I'd be honoured! (Is it not 16-point though, or is there a hole in my understanding?)

For all my ranting recently, let it be known that I am seriously impressed by much of the work that's gone into Max 6. As you say, the benefits of [gen~] extend far beyond processor savings.

Thank you all for the feedback. There are many things to balance w/r/t performance, quality, multi-threading, seamless audio, etc., and we will be working to improve performance both before and after the release.

Here are a few things to keep in mind regarding performance testing:

- What is in this beta is not a debug build, and there are some unresolved issues. We acknowledge that.

- We take performance seriously, and are working on these issues (as well as many other aspects of the software, which are equally important to address).

- Some things are faster, some things are slower in Max 6. Some of that will remain the case even after release.

- There are a variety of priorities we are balancing. Performance will sometimes suffer at the expense of quality, flexibility, and maintainability. You are always welcome to continue to use Max 5 (or Max 4) for the situations where you find it performs better if you prioritize performance over quality and flexibility.

- Multi-processor support does incur some costs and we'll be working in the short and long term to improve this.To adequately compare a comparable Max 5 and Max 6 patch, please disable multi-threading support in the Max preferences to take any multi-threading overhead out of the equation. This is especially the case when trying to compare 1% vs. 3%. CPU.

- Whenever possible, please give us detailed examples of the performance tests you are making. Thank you to those who have already done so. We will make use of them and improve them where possible.

- Some things about using 64bit do come at a cost (e.g. among other things it uses more memory for signal vectors, and hence cache performance will not be as good). We think that the audio quality makes some of these performance costs worth it.

- Some things about the mixer also come at a cost (e.g. patcher cross fading while editing). We'll be trying to make this easier to configure UI wise so that you can more easily configure for seamless audio vs. CPU performance.

- For the initial Max 6 release, we will not be focusing on less maintainable SIMD code, though over time we will be investigating this more, both in the existing object set and in code generation.

I hope this helps to address some of the questions and concerns raised in this thread. We have some good ideas in a variety of these areas, and we hope that in the next public release, you will find some improvements.

Your continued feedback is important to us. Please keep letting us know how we can make things better. It might not always happen in the time you like, but as a small team working hard on a project we care about, for a community of talented and interesting people, we try hard to make Max something that is enabling rather than limiting.

- Some things are faster, some things are slower in Max 6. Some of that will remain the case even after release. 

- Multi-processor support does incur some costs and we'll be working in the short and long term to improve this.To adequately compare a comparable Max 5 and Max 6 patch, please disable multi-threading support in the Max preferences to take any multi-threading overhead out of the equation. This is especially the case when trying to compare 1% vs. 3%. CPU. 

- Whenever possible, please give us detailed examples of the performance tests you are making. Thank you to those who have already done so. We will make use of them and improve them where possible. 

- Some things about using 64bit do come at a cost (e.g. among other things it uses more memory for signal vectors, and hence cache performance will not be as good). We think that the audio quality makes some of these performance costs worth it. 

- Some things about the mixer also come at a cost (e.g. patcher cross fading while editing). We'll be trying to make this easier to configure UI wise so that you can more easily configure for seamless audio vs. CPU performance. 

Thank you for taking the time to give such a thorough reply! Thumbs up to all the above! :)

I made the CPUtests of leafcutter, but needed to reduce the number of voices to 20...

version CPU% reported by Max CPU% reported by Activity Monitor

Max 4.6 24% Activity Monitor: 31% after closing idle 9%

Max 5.1 29% Activity Monitor: 39% after closing idle 10%

after closing a different patch (10*gizmos) idle consumption went down to 6%

version CPU% Max (w/parallel) CPU% Activity Monitor (w/parallel)

The cost for 64-bit sound seems high at the moment. I appreciate the efforts to make it better. I really love the gen~ object and the overall enhancements within the work flow...

20 voices non Poly~
version    CPU% reported by Max         CPU% reported by Activity Monitor
Max 4.6    24%  Activity Monitor:       31% after closing idle 9%
Max 5.1    29%  Activity Monitor:       39% after closing idle 10%
Max 6.0    37%  Activity Monitor:       53%
after closing the patch idle            20%
after closing a different patch (10*gizmos) idle consumption went down to 6%

20 voices within Poly~
version    CPU% Max    (w/parallel)     CPU% Activity Monitor (w/parallel)
Max 4.6    25%     -    n/a      -        32%         -          n/a
Max 5.1    31%     -    19%      -        41%         -          44%
Max 6.0    40%     -    26%      -        52%         -          55%-62%

The cost for 64-bit sound seems high at the moment. I appreciate the efforts to make it better. I really love the gen~ object and the overall enhancements within the work flow...


I must say (for the moment) that for me and my laptop:

The reasons are well explained in this post.

I also find that 64-bit is a feature at a great cost of CPU, firing numbers beyond any control.

And unfortunately I can't estimate the audio quality with my ears on my own work.

My patch is the outcome of three years of work on Max5,

that finally has found the right balance of Performance / CPU / GUI,

making large use of Max, Msp and Jitter togheter.

Max6 is simply unable to do the same job, also due to a very slow GUI response,

that can cause a crash if the patch opened has a relative density of patch cords to rebuild.

Yes, the GUI is more charming, more user friendly, more...

I don't consider myself a skilled user and I don't want to belittle the work done at Cycling,

I'm just realistic about what it concerns my experience,

I must say (for the moment) that for me and my laptop:
MacBook Pro i7, 2,3 GHz, 8 GB, OSX.6.8

The reasons are well explained in this post.
I also find that 64-bit is a feature at a great cost of CPU, firing numbers beyond any control.
And unfortunately I can't estimate the audio quality with my ears on my own work.

My patch is the outcome of three years of work on Max5,
that finally has found the right balance of Performance / CPU / GUI,
making large use of Max, Msp and Jitter togheter.

Max6 is simply unable to do the same job, also due to a very slow GUI response,
that can cause a crash if the patch opened has a relative density of patch cords to rebuild.
Yes, the GUI is more charming, more user friendly, more... 

I don't consider myself a skilled user and I don't want to belittle the work done at Cycling,
I'm just realistic about what it concerns my experience,
and at the moment I can't glorify Max6.

You didn't update. Max5 is still available on your computer.

Max 6 isn't useless; I've found some good uses out of it. I'm sorry that you haven't been able to notice differences in 64 bit audio. Here's a hint to where you might find improvements: 

https://cycling74.com/articles/max-6-sneak-peek-msp-audio-quality/

You are an early adopter and may need to find out why some of these things are happening and report them. They could be bugs that help everyone. That's part of the responsibility that comes with the benefit of using the software immediately.

All of the things you have mentioned can be tuned in preferences and options. I would try that as well. If you use this as a learning experience to figure out tuning max preferences and figuring out where bottlenecks are, you will certainly be a lot closer to being a skilled user. I don't want to belittle your experience right now. I want you to realize that you have a lot of options that will inevitably make you a better coder.

You didn't update. Max5 is still available on your computer. 

Max 6 isn't useless; I've found some good uses out of it. I'm sorry that you haven't been able to notice differences in 64 bit audio. Here's a hint to where you might find improvements: https://cycling74.com/articles/max-6-sneak-peek-msp-audio-quality/

All of the things you have mentioned can be tuned in preferences and options. I would try that as well. If you use this as a learning experience to figure out tuning max preferences and figuring out where bottlenecks are, you will certainly be a lot closer to being a skilled user. I don't want to belittle your experience right now. I want you to realize that you have a lot of options that will inevitably make you a better coder.


> You didn't update. Max5 is still available on your computer.

Can you be more clear? Am I forgetting to read some documentation about it? Or even some post?

>Max 6 isn't useless; I've found some good uses out of it. I'm sorry...

I can't estimate the audio quality, since my patch doesn't run properly in Max6 as it does in Max5.

This great cost of CPU causes an enormous latency with obvious consequences on the audio signal.

Yes, I've seen all the documentation came out since the Beta release

but usually I don't admire something that can improve my work till it really does it.

>All of the things you have mentioned can be tuned in preferences...

Unfortunately there's nothing to tune, nothing that can magically quiet a nervous CPU performance.

Bugs > a very slow GUI response that can cause a crash.

I don't think to be the only one here to experience this.

> You didn't update. Max5 is still available on your computer.
Can you be more clear? Am I forgetting to read some documentation about it? Or even some post?

>Max 6 isn't useless; I've found some good uses out of it. I'm sorry...
I can't estimate the audio quality, since my patch doesn't run properly in Max6 as it does in Max5.
This great cost of CPU causes an enormous latency with obvious consequences on the audio signal.
Yes, I've seen all the documentation came out since the Beta release
but usually I don't admire something that can improve my work till it really does it.

>All of the things you have mentioned can be tuned in preferences...
Unfortunately there's nothing to tune, nothing that can magically quiet a nervous CPU performance.

I don't think to be the only one here to experience this.


^ To be fair, both Max 5 and 6 crash on me on a pretty regular basis, even when patching simple things. I've learned to live with it, and to save often. This sucks big hairy plums, but I don't think it's got any worse with Max 6.

Max 6 isn't useless; it's a great new piece of software with teething troubles... but it IS a CPU hog, and the difference is noticeable. Those of us with big patches that Max 6 seemingly can't sustain are entitled to our grumbling. It's not fair to dismiss someone's valid complaint by suggesting he become a "better coder", even if he was a bit brusque.

http://en.wikipedia.org/wiki/Moore%27s_law

i really appreciate cycling74 for focusing on quality.

I personally wont buy max 6 too soon because of the performance hit.

I don't understand the discussion, but it's nice to get those benchmarks on a regular basis.

http://en.wikipedia.org/wiki/Moore%27s_law
i really appreciate cycling74 for focusing on quality.
I personally wont buy max 6 too soon because of the performance hit.
I don't understand the discussion, but it's nice to get those benchmarks on a regular basis.


Because I think this topic must be on the top of the paradigms to take in consideration in Max6.

And because I don't understand why I must start to think smaller in Max6

with the latest generation laptop. I love quality too, Max itself is quality,

64-bit processing audio means a great quality.

I plain to use just Max6 for any audio application

and don't corrupt audio recordings / performances

through any plugin or other softwares with ambiguous algorithms.

and I'd like to know that in the next future I can finally taste it.

As christripledot said, thanks... it happens especially to who is keen on building big patches.

Of course, it's hard to find solutions for every taste.

Because I think this topic must be on the top of the paradigms to take in consideration in Max6.
And because I don't understand why I must start to think smaller in Max6
with the latest generation laptop. I love quality too, Max itself is quality,
64-bit processing audio means a great quality.
I plain to use just Max6 for any audio application
and don't corrupt audio recordings / performances
through any plugin or other softwares with ambiguous algorithms.

But now I've a candy that I can't unwrap 

and I'd like to know that in the next future I can finally taste it.
As christripledot said, thanks... it happens especially to who is keen on building big patches.
Of course, it's hard to find solutions for every taste.


Have a look at 6.0.1. We addressed a lot of performance issues. Hopefully this candy you can unwrap.

@ lasmiveni
Have a look at 6.0.1.  We addressed a lot of performance issues.  Hopefully this candy you can unwrap.


"But now I've a candy that I can't unwrap"

I feel the same way because i am also building one big patch since a couple of years that i'm quite sure won't work with max 6 because of performance issues. And i dodn't want to stop the discussion, i just find that the point really is that a company decided to do the next step to early for our budget..

MSP performances in Max/MSP 6