Or we can add a switch to disengage very CPU expensive code of level detector and exchange it with very good and similar sounding but more traditional solution. This would allow us to have the plug-in almost twice faster. There is very little space to optimize current version of MC without any cuts on the algorithm.

Regards,

- thanks, Mateusz! I'm glad you're working on it. Any or all of those ideas/improvements would be good.

I'm not through setting up my Intel Mac for work, yet - so I'm mainly back on my PPC. I'll try to post more findings during the work transition.

I have noticed one thing that I hadn't before, though - sometimes when I turn off FAT or even bypass MC, I don't seem to get any CPU usage reduction.

Mateusz, 2 questions:

1. Have you ever specifally tested MC running on a Protools HD, TDM system? If so, which OSX versions have you tested?

My system:
MacPro quad 2.6
4 gb ram
OSX 10.4.11
PTHD 7.4.2
Mastercomp ilok version 1.5.4


Disclaimer: I have ZERO experience as a programmer so I am making no claims or assertions here, just a end user's question...

2. I don't understand how this can be a simple case of MC being CPU hungry. Other plugins seem to respond to computer power upgrades in a more or less proportional manner. MC actually performs LESS efficient on some newer, industry standard machines such as Macpros. What is the explanation for this anomoly?

Thanks for your responses on this thread,

-Zak

Hello,

I made various comparisons on my Core 2 Duo macintel and it looks like in every application there is a huge CPU usage for PSP MC PT 7.4 performance looks similar however PT looks more sensitive to CPU usage then some other applications.
This plug-in was designed for mastering purposes so we didn't care CPU usage, it was also developed on Pentium M and it was working pretty good for its complexity.
The comparison between PC and Mac version shows that the MS compiler deals a bit better with MasterComp's code then XCode does.
Sadly switching to newer CPUs may give a worse performance in some cases. In the case of the MasterComp the algorithm is like a series stream of processing instructions, they cannot be reorganized in the way to get easy through a nowadays more parallel architecture.
So we cannot make considerable optimizations without changing the code. This is why I think about giving some options to internally simplify some unusual - hyper-hi-end parts of the code.
So if you want all bits of the MasterComp with FAT on and limiter on, RMS and soft knee you will not get easy on CPU, at least we have no exact solution right now. If you need most of its features and need the MasterComp in the mix I think the option to simplify the algorithm in its most mastering parts is a good idea.

Regards,

it is posible to do a TDM version ?

We don't plan any TDM versions nowadays.

Regards,

Is it just me or does the FAT mode seem to suck out the low mids,I've just been realizing this lately, what exactly happens in FAT mode? I still use this more than any comp I have but I'm tending to hold back on the FAT mode.

There is no difference in the algorithm except that the plug-in is working in doubled sample rate. The conversion itself is very transparent.

Regards,

i hatve to desable Fat mode to.I am too sory becuse i buy the MC and Neon.i use now just for small project.Anyway...vst is work good.but i want MC to work good in pro tols to.

i don't notice performance difference between RTAS and VST but I always noticed that Pro Tools is more fragile to high CPU usage and stops processing earlier then other hosts even with high CPU limit setup.

Regards,