Forums > MaxMSP

feature request : better way to handle patch loading

June 8, 2012 | 9:42 am

Hello,

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…


June 8, 2012 | 12:14 pm

Here’s what I do (works well for me in quite large/complex patches):

– Pasted Max Patch, click to expand. –

June 8, 2012 | 12:44 pm

hm ok
maybe this is enough, thanks.



jbl
June 8, 2012 | 3:54 pm

This is smart, thanks Zachary.


June 8, 2012 | 4:49 pm

You might find this thread interesting: http://cycling74.com/forums/topic.php?id=38265


June 9, 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.


June 9, 2012 | 2:56 pm

is there an equivalent of deferlow inside qlist ? Or do you need to use timed delays for this purpose ?


June 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.

– Pasted Max Patch, click to expand. –

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