feature request : better way to handle patch loading

Jun 8, 2012 at 9:42am

feature request : better way to handle patch loading

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…

#50083
Jun 8, 2012 at 12:14pm

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

– Pasted Max Patch, click to expand. –
#179834
Jun 8, 2012 at 12:44pm

hm ok
maybe this is enough, thanks.

#179835
Jun 8, 2012 at 3:54pm

This is smart, thanks Zachary.

#179836
Jun 8, 2012 at 4:49pm

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

#179837
Jun 9, 2012 at 2:01pm

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.

#179838
Jun 9, 2012 at 2:56pm

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

#179839
Jun 11, 2012 at 6:04pm

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. –
#179840

You must be logged in to reply to this topic.