personal_username

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 ;-)

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?

patch-veeery-slow-to-behave-smoothly

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

This way I can determine the order in which things get initialized,

It adds a little time to my startup, but everything always starts up

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.


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

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


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

My implementation of Chris Muirs suggestion:

Save abstraction as "loadpercent.maxpat":

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

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


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

See Max Basic Tutorial 15 – Abstractions

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.

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.


Patch veeery slow to behave smoothly