(feature request) Loadbang delay argument

In a complex giant patcher, the initialization gets quite complex. The method I settled on, in the largest patch that I use, is to start a metro/counter at the top left corner of the top level patch that counts to 100 at a rate of 5ms / tick. I send this value around via a [send load_percent] and elsewhere in the patch I compare load_percent to some threshold, and initialize when load_percent has crossed that threshold. This allows me a deterministic order of initialization across a giant patch, albeit at the cost of a half second longer load time.

i use an abstraction which allows 9 arguments for 9 different delay times.

Thanks for the ideas!

I don't understand why having the delay built into loadbang would be any better than using a delay object. (That's what it's made to do: delay a bang.)

A different approach would be to use a single loadbang at the top level and use send or forward to send the messages you want where you want in the order you want. What with all the objects such as b, t, delay, pipe, uzi, etc., you can construct about any sort of ordering system you want. Here's a ludicrous example.

I wrote a javascript implementation of an ordered [loadbang] which you can find in the linked blog post. If you skip back to the previous post there is a bit more of an explanation. Otherwise I often tend to use one master [loadbang] and use an approach similar to the method Chris suggested. I hope it helps.

lh

I wrote a little abstraction to do delayed loadbangs.
The first (optional) argument specifies a delay time in ms. (Optional)arguments after the first one will be sent out as a message after the delay (so it's loadbang and loadmess with a delay function).

Stick it in a patcher, save it as 'loadbangdelay' (that's how I named it anyway) and put it in the Max path.

Be prepared to discover that this scheme (delaying loadbangs) not always works flawlessly. What I found to work better is that a process which has finished (eg loading a file, filling a buffer) triggers the next step in the sequence. And I use deferlow abundantly. The scheduler's ways are unfathomable (sometimes).

For me Initialization order is the most tricky and mysterious part of Max.
In particular, I wonder how to handle self-initializing live.* objects in combination with loadbang initializations of other objects.

Any comments on this?

@broc, total agreement (as you know!).

i used to think i had a pretty good handle on max initialisation, but since m4l and live.* objects came along, the thing is a minefield. every time i do anything i build test patches which give me different results to the last initialisation-test-patches i made.

so, +1 to broc, any comments always good...

(p.s. - gives me great heart to read the great jvkr's comment "The scheduler's ways are unfathomable (sometimes)")...