Patch veeery slow to behave smoothly

    Feb 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?

    • Feb 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.
    • Feb 24 2012 | 7:49 pm
    • Feb 24 2012 | 11:45 pm
      nice, indeed! looks like a lot of different [>] made one by one, if I get it right
    • Feb 25 2012 | 12:31 am
      They probably don't all need to be at different times, but yeah.
    • Feb 25 2012 | 10:13 am
      My implementation of Chris Muirs suggestion:
      Save abstraction as "loadpercent.maxpat":
      The loadpercent sender patch:
    • Mar 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?
    • Mar 25 2012 | 8:54 pm
      #1 is not strictly speaking an attribute, but rather an argument.
      See Max Basic Tutorial 15 – Abstractions
    • Mar 28 2012 | 11:08 am
      thanks! thats great!
    • May 12 2015 | 8: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.