Forums > MaxMSP

Patch veeery slow to behave smoothly


February 24, 2012 | 5:48 pm

Hi all!
I have something like 280 loadbangs in my patch, and i thing this is the reason why it starts reacting properly after more than 60000 milliseconds. Which I know you know is a minute ;-)

I wish to have just onebang which drives sequentially the other ones,as i read this could speed up performance.
But If everything was in the same window, no problem: just a [t b b b b b b etc.] would have done it. But what if I have multiple subpatchers (so no direct patchords)? I don’t know what’s the best way to efficiently do that.

Ah… and I *hope* the slowdown is a loading issue and not another one…: 280 loadbangs to trigger in order is not a very fun game ;-)
Any tip?

thanks!

February 24, 2012 | 6:26 pm

In my biggest patch, I adopted a scheme that works pretty well for me.
In the upper left corner of my top-level patch, I have a sub-patcher
that receives a loadbang, and starts a process of counting to 100,
driven by a metro. I distribute this value via [s LoadPercent]. Then
in all my abstractions, bpatchers, and subpatchers, I have an [r
LoadPercent] and fire off my local initialization when the LoadPercent
exceeds some threshold.

This way I can determine the order in which things get initialized,
across a giant, sprawling, patch.

It adds a little time to my startup, but everything always starts up
in the proper order.

February 24, 2012 | 7:49 pm

nice

February 24, 2012 | 11:45 pm

nice, indeed!
looks like a lot of different [>] made one by one, if I get it right

February 25, 2012 | 12:31 am

They probably don’t all need to be at different times, but yeah.

February 25, 2012 | 10:13 am

My implementation of Chris Muirs suggestion:

Save abstraction as "loadpercent.maxpat":

– Pasted Max Patch, click to expand. –

The loadpercent sender patch:

– Pasted Max Patch, click to expand. –
March 25, 2012 | 8:11 pm

hi!
how did you know how to use patches attributes like – sel #1? is it discussed in some help file?

March 25, 2012 | 8:54 pm

#1 is not strictly speaking an attribute, but rather an argument.

See Max Basic Tutorial 15 – Abstractions

March 28, 2012 | 11:08 am

thanks! thats great!

May 12, 2015 | 1:38 pm

I implemented something very close to this, but I ran into a stumbling block.

Because I was having problems with pattr binds not being found, I decided to wait till the whole patch is done to load them. So I made a binding abstraction. Problem is, whatever percent I put this abstraction at, all instances fire at the same time. I’d like to space them out, because it’s several minutes before they all get themselves sorted out. But I’d rather not send each one a bang order externally.

I’m thinking there might be a way with a global variable that each instance can change? Maybe the first one to trigger at X% sets % back to x-1%….. thinking out loud here. (then it would have to flag itself as loaded the next time the % hit, I guess….)

I guess I can always embed bang% as an argument to the abstraction. Probably easier in the long run, and more precise. But in my case, I just need some things (pattrs/poly) in place before the binds, and some things to wait until they are done. I don’t think the actual order of the binds matters.

Viewing 10 posts - 1 through 10 (of 10 total)

Forums > MaxMSP