Patch veeery slow to behave smoothly

personal_username's icon

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!

Chris Muir's icon

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.

woyteg's icon

nice

personal_username's icon

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

Chris Muir's icon

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

Karl Kliem's icon

My implementation of Chris Muirs suggestion:

Max Patch
Copy patch and select New From Clipboard in Max.

Save abstraction as "loadpercent.maxpat":

Max Patch
Copy patch and select New From Clipboard in Max.

The loadpercent sender patch:

ćwiek's icon

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

Chris Muir's icon

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

See Max Basic Tutorial 15 – Abstractions

ćwiek's icon

thanks! thats great!

woodslanding's icon

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.