feature request : better way to handle patch loading

    Jun 08 2012 | 9:42 am
    After having my patch systematically crashing when i send a bang into a "send init"-like thingy, i'm starting to wonder why this can't be handled better by Max. It could be nice to have, say, a loadbang thing that sends a first bang somewhere, waits for the task to be finished, posts the result in Max windows, then sends another bang for another task etc, until all necessary bangs are banged. Couldn't this kind of thing prevent startup crash ? In my opinion, it's something crucial Max lacks... there might be ways to do those kind of things, but those are complicated, and knowing when e.g. a poly~ has loaded all its instances and is ready not to crash, a pattrstorage has sent all his saved states and all have been accepted clearly, a thispatcher has accomplished all creation/connect/whatever scripts sent to him is not always easy...

    • Jun 08 2012 | 12:14 pm
      Here's what I do (works well for me in quite large/complex patches):
    • Jun 08 2012 | 12:44 pm
      hm ok maybe this is enough, thanks.
    • Jun 08 2012 | 3:54 pm
      This is smart, thanks Zachary.
    • Jun 08 2012 | 4:49 pm
    • Jun 09 2012 | 2:01 pm
      Since a few time I used the same way as Zachary. But now, I use qlist, I think it's a better way to initialize a patch. It's easy to manage in which order commands come.
    • Jun 09 2012 | 2:56 pm
      is there an equivalent of deferlow inside qlist ? Or do you need to use timed delays for this purpose ?
    • Jun 11 2012 | 6:04 pm
      Qlist is only a text object. Deferlow may be used after a receive object.
      Here an example how I use qlist.