Lambros Pigounis

I'm using 2 rather big patches I have made with 8 waveform objects, 4 filtergraphs, granular effect, time stretching, waveshaping and filter interpolations. I also use 4 adc~ objects along with some resonance transformations (cnmat).

So, while playing around, taking audio in, processing and playing back some files, the cpu starts slowly increasing until it reaches to 90+ sometimes 100% and then of course glitches and distorted audio.

At this momment I always restart the audio engine and cpu comes back to normal (15-35 usually with these patches).

I would appreciate if somebody could give me a few tips for cpu handling in patches like the ones I described. I understand that some user interface objects I use might be one of the reasons. But unfortunately I haven't worked around that much more for the time being.

system:
macbook pro i5 2.53GHz
MaxMSP 5.1.4
OS X 10.6.3

I'm using 2 rather big patches I have made with 8 waveform objects, 4 filtergraphs, granular effect, time stretching, waveshaping and filter interpolations. I also use 4 adc~ objects along with some resonance transformations (cnmat).
So, while playing around, taking audio in, processing and playing back some files, the cpu starts slowly increasing until it reaches to 90+ sometimes 100% and then of course glitches and distorted audio.
At this momment I always restart the audio engine and cpu comes back to normal (15-35 usually with these patches).

I would appreciate if somebody could give me a few tips for cpu handling in patches like the ones I described. I understand that some user interface objects I use might be one of the reasons. But unfortunately I haven't worked around that much more for the time being.
So, any insight is much appreciated

cpu-gradual-increase

You should try to remove or isolate some parts of your patch to find where the CPU is spending all its time.

I remember there were some problems with denormal numbers in some of cnmat's externals in the past (and not only with cnmat), like 

. Are you sure you used the lastest version of their great externals?

I remember there were some problems with denormal numbers in some of cnmat's externals in the past (and not only with cnmat), like smooth-biquad. Are you sure you used the lastest version of their great externals?

1 - you are turning on processing / changing the parameters in such a way that the CPU usage increases naturally to this point - in which case you need to manage your CPU more carefully.

2 - if the CPU rise is very gradual and seems unconnected to how much stuff you are doing there may be a problem with denormals (as Patricksays) in one of your externals (you can google to find out more on what these are). In this case there is no standard max way to solve this - you should contact the maker of the external to make them aware of it, or download a corrected version if one exists..... I can also mention that I have created an external which can be used to switch denormals off for the processor to avoid this problem, without having to get a corrected version of the external.

Either way if you post the patch we can advise more. Ideally post the patch and a set of steps to drive the CPU too high....

2 - if the CPU rise is very gradual and seems unconnected to how much stuff you are doing there may be a problem with denormals (as Patricksays)  in one of your externals (you can google to find out more on what these are). In this case there is no standard max way to solve this - you should contact the maker of the external to make them aware of it, or download a corrected version if one exists..... I can also mention that I have created an external which can be used to switch denormals off for the processor to avoid this problem, without having to get a corrected version of the external.

Does your memory usage go up as well as the CPU?

1. yes I think that cnmat's (latest version) externals, like resonators and res-transform are probably using most of the proccessing power. I have added some automation to them, so....I guess that should be my first place to look.

2. turning on processing / changing the parameters is also another busy state to which I get and finally I must add that the cpu rises very gradually (something I forgot to mention in my first post)

In this case, I do need to: a)remove or isolate some parts of the patch and b) pay attention to the way I treat numbers and proccessing so that I can figure out where the rise starts.

3. No my memory usage do not go up. fortunately...

1. yes I think that cnmat's (latest version) externals, like resonators and res-transform are probably using most of the proccessing power. I have added some automation to them, so....I guess that should be my first place to look. 

2. turning on processing / changing the parameters is also another busy state to which I get and finally I must add that the cpu rises very gradually (something I forgot to mention in my first post)
In this case, I do need to: a)remove or isolate some parts of the patch and b) pay attention to the way I treat numbers and proccessing so that I can figure out where the rise starts.

Very gradual CPU rise that will not stop is a characteristic of denormal problems. It is is I guess possible in other cases, but unlikely. It is also common for the cpu to return to normal when audio is restarted after a denormal issue, without changing any settings...

It is much easier to help if you can post the patch concerned....

To be honest I was aware of such an issue as the denormal numbers. I would appreciate if you could explain what these numbers are and what they can cause.

so, yes I have to restart the audio (and without changing any settings)so as to bring the cpu back to "normal".

I will post the patch as soon as I can. Sorry I'm not able to do that right now.

hello
thank alex for the tip.
To be honest I was aware of such an issue as the denormal numbers. I would appreciate if you could explain what these numbers are and what they can cause.
so, yes I have to restart the audio (and without changing any settings)so as to bring the cpu back to "normal".

I will post the patch as soon as I can. Sorry I'm not able to do that right now.
I'll get back to you asap.

.....to be honest I was NOT aware of such an issue as the denormal numbers.....

http://en.wikipedia.org/wiki/Denormal_number

Some processors handle denormal values in hardware, in the same way as normal values. Denormal arguments or results thus pose no particular performance issue; they are handled at the same speed as normal values. But some processors leave the handling of denormal values to system software, only handling normal values and zero in hardware. In this case, computing with denormal values is significantly slower than computing with normal values.

Some applications need to contain code to avoid denormal numbers, either to maintain accuracy, or in order to avoid the performance penalty in some processors. For instance, in audio processing applications, denormal values usually represent a signal so quiet that it's out of the human hearing range. Because of this, a common measure to avoid denormals on processors where there would be a performance penalty is to cut the signal to zero once it reaches denormal levels or mix in an extremely quiet noise signal.

Denormal number
http://en.wikipedia.org/wiki/Denormal_number

Some applications need to contain code to avoid denormal numbers, either to maintain accuracy, or in order to avoid the performance penalty in some processors. For instance, in audio processing applications, denormal values usually represent a signal so quiet that it's out of the human hearing range. Because of this, a common measure to avoid denormals on processors where there would be a performance penalty is to cut the signal to zero once it reaches denormal levels or mix in an extremely quiet noise signal.


btw, I try to upload the patch but it doesn't let me do it....

If I understand well, it is mainly a matter of how much and how I mix my signal during processing.

It is true that the rise of the cpu happens when there is some activity in the resonance subpatch along with a lot of other procesing happening in the forground patch.

it is an ongoing work with quite a few externals etc...

If I understand well, it is mainly a matter of how much and how I mix my signal during processing.
It is true that the rise of the cpu happens when there is some activity in the resonance subpatch along with a lot of other procesing happening in the forground patch.
it is an ongoing work with quite a few externals etc...

For a strange reason, I could not upload the main patch which includes the one I just uploaded. I can't be sure which is the patch that generates the denormal numbers. If you still have the time to have a look at it, I would really appreciate it.

Any idea why it doesn't let me upload the "master" patch?

One last question is how would I be able to realise if a patch, or preocess in a patch, generates denormal numbers?

For a strange reason, I could not upload the main patch which includes the one I just uploaded. I can't be sure which is the patch that generates the denormal numbers. If you still have the time to have a look at it, I would really appreciate it.
Any idea why it doesn't let me upload the "master" patch?

Had a quick look but couldn't get it to run over 2% on my CPU.

Generally denormals occur when the input to a recursive filter or other feedback algorithm is at zero, and are characterised by a steadily rising CPU usage. There is no way using standard max objects to be sure that the problem is denormals.

There may be a limit on the max size of attachments?? How big is the main patch? Also - do you have a set of reliable steps to reproduce the problem?

CPU gradual increase