ComfortableInClouds

Hi - a large part of my use of Max is building sequencers.One of the sequencers I use most often I just added several elaborations to - that is, sequencers nested within this sequencer to control different parameters. However, this sequencer I use in a lot of my patches, and when I opened a monster patch of mine I use for improvising/sketching ideas, my CPU usages shot up to 100% (before it was around 30%). I deleted three out of the four sequencer I had nested within my main sequencer, and my CPU % went down to about 55%. However, even still I get glitches at 55%. Is there any method to stop control objects from eating up CPU? I know [pcontrol] disables MIDI, but I'm not using MIDI for my sequencer.

an-equivalent-to-mutepoly-for-max-objects

I have the same doubt, because I want to make a huge polyfonic synth, with 16 voices of poliphony, each one with 7 partials, with option of 4 types of wave.. so I also need to use this stuff..

I know that it is possible to disable audio processing with mute.. Me and a friend have been trying to implement that with no sucess.. I also know that it is possible to disable a portion of audio with a message for poly~ (I think that you have to use a message called target, at least I think that a friend of mine told me that) but poly as some bugs in max5, at least as some people have told me

Maybe you should post your sequencer model here, so we can maybe improve it ?

I guess that if your seq eats up to 55% (without audio) then it's badly designed...

[poly~] works fine with max5 (at least for me)

Maybe you should post your sequencer model here, so we can maybe improve it ?
I guess that if your seq eats up to 55% (without audio) then it's badly designed...

@tiaglo
[poly~] works fine with max5 (at least for me)

It's not that the sequencer eats up 55% on its own - it eats up between 0 - 2% when just one is running. It's when I open a patch that uses the same sequencer 3 dozen times, along with other sequencers, on top of dozens of samplers and effects. I'll post the sequencer anyways, in case someone has a better idea for it. But honestly, i don't think it's poorly designed at all. Just too clunky to be used in excess.

To the first reply - mute~ does work. You want to put a pass~ on the outlets of any subpatcher you mute, as well as use a [$1 1] message to mute subpatchers within the muted patch. If you're making a polyphonic synth, you want to use poly~, which works fine in Max 5.But I am concerned with disabling Max, not MSP objects.

Anyways, here is the sequencer if anyone has suggestions. You want to open the file "GenericSeq+~" - that's the main sequencer. "GenericSeqMax" is the nested sequencer whose functions I would like to be able to disable. Use the patch titled "SequencerHeart" to set the BPM, toggle on/off or reset.

To the first reply - mute~ does work. You want to put a pass~ on the outlets of any subpatcher you mute, as well as use a [$1 1] message to mute subpatchers within the muted patch. If you're making a polyphonic synth, you want to use poly~,  which works fine in Max 5.But I am concerned with disabling Max, not MSP objects.

Anyways, here is the sequencer if anyone has suggestions. You want to open the file "GenericSeq+~" - that's the main sequencer. "GenericSeqMax" is the nested sequencer whose functions I would like to be able to disable. Use the patch titled "SequencerHeart" to set the BPM, toggle on/off or reset.


I didn't delve too deep into you patch so I'm not sure if there is a problem or not but here are a couple of hangups I've run into-

1) Graphical updates. I've found that having little things like using a slider to indicate the current bar/beat or maybe interpolate between presets is no big deal until you have 12 of them going at the same time. I currently add an extra gate/toggle thing to turn graphical updates on/off. Either that or look for other object that have a similar data structure but doesn't use graphics. This saves a lot of CPU.

2) Feedback. Sometimes I work with doing iterative changes to max messages using a combination of pipe/delay and then some other message processing. This can get nasty really fast. Obviously if its just straight feedback loop its going to overflow right away. But if you delay it, it generally wont but just slowly eat up cpu.

I think that in general, instead of using mute~ just try to put a gate at the top of your sequencer to turn it on and off. Yes, messages will still hit the gate but at least they stop right there.

I didn't delve too deep into you patch so I'm not sure if there is a problem or not but here are a couple of hangups I've run into- 

1) Graphical updates. I've found that having little things like using a slider to indicate the current bar/beat or maybe interpolate between presets is no big deal until you have 12 of them going at the same time. I currently add an extra gate/toggle thing to turn graphical updates on/off. Either that or look for other object that have a similar data structure but doesn't use graphics. This saves a lot of CPU. 

2) Feedback. Sometimes I work with doing iterative changes to max messages using a combination of pipe/delay and then some other message processing. This can get nasty really fast. Obviously if its just straight feedback loop its going to overflow right away. But if you delay it, it generally wont but just slowly eat up cpu. 

I think that in general, instead of using mute~ just try to put a gate at the top of your sequencer to turn it on and off. Yes, messages will still hit the gate but at least they stop right there.


Seconded, more [gate] sounds like a good idea.

[gate] seems like a simple, sensible solution i guess toggles are kind of the Max equivalent to mute~, never thought about it like that thanks for the advice!

[gate] seems like a simple, sensible solution  i guess toggles are kind of the Max equivalent to mute~, never thought about it like that  thanks for the advice!


Just attempted a master on/off for each of the nested sequencers - my CPU still craps out. I think I might just have to trim my patch down. Oh well - it will be a good exercise to reevaluate my work flox.

mmh, and how much is your cpu in the same patch with the dozens of samplers and effects but without seqs ?

Each time I ran into cpu problems, it was caused by the audio part.

Each time I ran into cpu problems, it was caused by the audio part.
Maybe you should have a look there ?

yes it kind of sounds like its something else. I mean, if you have a dozen sequencers with gates set to 0, it shouldn't be any more cpu intensive than a dozen gate objects.

So I have run some tests seeing how my CPU performs with different variations on this sequencer:

my giant patch w/o the sequencers at all is running at 25-27% CPU.

with the sequencers in the patch but not running (i have a global on/off for my sequencers (except for the nested ones, which have their own on/off), i am between 67 - 100%.

with the sequencers in the patch and the patch running, I am at 100% +.

with the sequencers in the patch, but without the nested sequencers, and the patch running i am at 30-31%.

To give an idea of my giant patch: in total, this sequencer appears in my patch 39 times. When I nest all the subsequencers within it, there are 4 more sequencers per sequencer (which means 195 sequencers of this type (there's betwen 1 - 2 dozen other kinds of sequencers within the patch. I like sequencers.). This is on top of about ~ 2 dozen samplers (3 different kinds), and 11 effects. Plus gain + routing + send~/receive~ objects.

What gets me though, is the jump in CPU when I nest my sequencers - even though the nested sequencers are all turned off - plus they aren't using MSP at all. No information is coming out of them or being generated within them since they are turned off. The only thing they have running inside of them is a single metro to quantize the on/off to my global BPM.

In terms of function calls, I have ~ 1100 function calls occuring. I'm on Mac 0S X 10.4.11, Macbook Pro, 17", Intel Processor.I am in overdrive (have to be for timing).

I mean, I would say that it's too many things needing to be done at once, but if a sequencer is turned off it isn't doing anything. Why then does it weigh so heavily on my CPU?

What gets me though, is the jump in CPU when I nest my sequencers - even though the nested sequencers are all turned off - plus they aren't using MSP at all. No information is coming out of them or being generated within them since they are turned off. The only thing they have running inside of them is a single metro to quantize the on/off to my global BPM. 

I mean, I would say that it's too many things needing to be done at once, but if a sequencer is turned off it isn't doing anything. Why then does it weigh so heavily on my CPU?


OK - so I realized that this patch is eating CPU for no reason. I have every single sequencer turned off, I have every DSP object muted - yet I am still at ~ 70% CPU usage, even having the occasional overload. My I/O vector size is a generous 1024, and signal vector size is 64.

How is that, with every sequencer turned off, and everything muted I am still eating up so much CPU? Is it simply the sheer amount of THINGS in the patch? Is there anyway to make Max just disregard things when they aren't doing something?

You say your sequencers are off, but each of them has a metro on, right? What if you turn these internal metros off as well?

Any difference? What if you put a gate after each of these internal metros?

You say your sequencers are off, but each of them has a metro on, right? What if you turn these internal metros off as well?
Any difference? What if you put a gate after each of these internal metros?


Each one of my nested sequencers has a "quarterpulse" bang object (see my zip file with my sequencers) to quantize when it gets turned on/off. this is turned off when my "Sequencerheart" patch is turned off (see my zip file).At this point, my giant patch takes up about 60-80% of my CPU. Here is my nested sequencer - it's the same as the one in the zip file except with the added on/off control. (note - you need several objects from my previously posted zip file for this sequencer to work, and you control its BPM and on/off using the SequencerHeart patch, also included in the zip file)"

When, in my Sequencer Heart patch, I have the master sequencer turned off, it means ALL metros are turned off. In my giant patch, every single DSP object has been muted. So - all DSP is supposedly off because of mute~, and every single metro has been turned off because its turned off in my sequencer heart - so why does my CPU sit between 60-80%?

How is it possible there's 1100 function calls when nothing is actually doing anything?? It's like I have literally thousands of objects creating hundreds of sequencers and devices - but all of them are off and not doing anything. Does their very existence really create that much of a CPU strain?

In tests with poly~, I found that creating this sequencer 39 times puts a 30-40% strain on my CPU. Why is this, even when the DSP part of the sequencer gets muted (i changed it so the main sequencer also gets turned on/off like the nested sequencer. doing this mutes/unmutes the DSP part of the sequencer), and each nested sequencer is turned off? The sequencers aren't doing anything.

When, in my Sequencer Heart patch, I have the master sequencer turned off, it means ALL metros are turned off. In my giant patch, every single DSP object has been muted. So - all DSP is supposedly off because of mute~, and every single metro has been turned off because its turned off in my sequencer heart - so why does my CPU sit between 60-80%? 

In tests with poly~, I found that creating this sequencer 39 times puts a 30-40% strain on my CPU. Why is this, even when the DSP part of the sequencer gets muted (i changed it so the main sequencer also gets turned on/off like the nested sequencer. doing this mutes/unmutes the DSP part of the sequencer), and each nested sequencer is turned off? The sequencers aren't doing anything.


Something else that I notice in your last patch is the use of [snapshot~].

Personally, I avoid this object as much as possible because it becomes cpu hungry when using too much of them. (I also avoid metro by the way, and use a custom [metro~]).

You could just map your value (or use [line 0.]) there and stay in non-signal mode instead of 

It's always good to cleanly separate signal from non-signal worlds in your patch.

Something else that I notice in your last patch is the use of [snapshot~].
Personally, I avoid this object as much as possible because it becomes cpu hungry when using too much of them. (I also avoid metro by the way, and use a custom [metro~]).
You could just map your value (or use [line 0.]) there and stay in non-signal mode instead of 
[float( -> [curve~] -> [snapshot~].
It's always good to cleanly separate signal from non-signal worlds in your patch.

gusanomaxlist wrote on Sat, 14 March 2009 17:30

THANK YOU! Removed curve~, replaced it with [line 0.] -> [pow] and my CPU is now at 17% with all sequencers turned off and everything muted. The CPU cost of snapshot~ was definitely the issue here. I didn't have a mute message routed to my subsequencers, I had forgotten that they had any MSP objects.

gusanomaxlist wrote on Sat, 14 March 2009 17:30Something else that I notice in your last patch is the use of [snapshot~].
Personally, I avoid this object as much as possible because it becomes cpu hungry when using too much of them. (I also avoid metro by the way, and use a custom [metro~]).
You could just map your value (or use [line 0.]) there and stay in non-signal mode instead of 
[float( -> [curve~] -> [snapshot~].
It's always good to cleanly separate signal from non-signal worlds in your patch.

THANK YOU! Removed curve~, replaced it with [line 0.] -> [pow] and my CPU is now at 17% with all sequencers turned off and everything muted. The CPU cost of snapshot~ was definitely the issue here. I didn't have a mute message routed to my subsequencers, I had forgotten that they had any MSP objects.


Another good trick with snapshot is to just have it running when you need it. This may not help if every patch is running curve->snapshot all the time but if only a few instances use it then you'll probably be ok. Its pretty easy to set up some logic to start snapshot when curve~ gets a list (try the trigger object) and then stops it with curve~'s second outlet.

An Equivalent to Mute~/Poly~ For Max Objects?