One Loadbang that Sends everyone or lots of loadbangs all over the place?
I'm thinking about the most effective ways to initialize my patch. Is it better to have one load bang into a send object, and put receives all over the place? Or is it better to just use loadbangs everywhere?
I found that the former is useful for staged initialization. If you feed the loadbang into multiple sends, you can control the order in which groups of things initialize.
But in a simple patch, say I want to use a few counters... and the counters require a "reset" to start at the minimum. Should I use a loadbang for each [counter] or should I send a single loadbang to all of them?
You can't guarantee the order the loadbangs fire, so using one is the only way to control the order of operations. Whether that is crucial depends on the complexity of your patch.
A loadbang inside an abstraction fires before a loadbang in a master patch.
More generally, any loadbang in a subpatch fires before any loadbang in the father patch.
Beyond that, [loadbang] -> [t...] is a way to control the order of operations.
if you need things to intialize in a certain order it is tempting to make a mother of all loadbangs with a t b b b b b b b b b b and then connect to inlets of subpatches or use s/r to reach the rest of the patch.
but in my experience you normally dont need that so often. if you design your abstractions and subpatchers always in a manner that their init state can be changed from outside, then you can loadbang the actual number or symbol requried from outside later where needed - but not the plain loadbang itself.
"You can't guarantee the order the loadbangs fire"
the order is totally predictable, but the question is how long you can follow it when a patch gets more and more complex.
otoh, when you want to control the order by a trigger, you have basically the same problem. :)
Grateful for this discussion.
Are there any performance concerns about spreading loadbangs all over the place?
Is it FASTER to just have one and route it everywhere? Or is managing the initialization sequence the only advantage t here?
Also, Roman, when you say, "if you design your abstractions and subpatchers always in a manner that their init state can be changed from outside, then you can loadbang the actual number or symbol requried from outside later where needed - but not the plain loadbang itself. "
I don't think I'm following you. Can you elaborate?
you can send several ten thousand of bangs within 1 ms, how they are organized is your least problem when a patch is loaded. poly~ 64 is slow, or loading videos from disk - not loadbang. :)
"Can you elaborate?"
sorry for the mess.
IMHO abstractions and subpatchers always should have their own loadbang process, just like externals do - but then also allow to send a value into an inlet to overwrite that default internal setting from outside.
then you can either do [foo 16] or [loadbang]-"5"-[foo] ... or both.
"you can send several ten thousand of bangs within 1 ms, how they are organized is your least problem when a patch is loaded."
That, indeed, is my case - upon loading my patch I need to initialise it by sending a huge number of loadbangs and loadmesses and I don't care about the sequence.
Isn't there a neat way to avoid the mess, the hassle and keep the patch tidy?
I guess it would be possible with JS, but unfortunately I don't know the language, so wouldn't help me much.
There must be some clever way for this to be done...
for up to 9 i use an abstraction...
[110.loadargs 1 2 3 a b c X Y Z 'this is a list'] ...or a trigger object...
...but if you plan to make them dynamic by arguments, nowadays [patcherargs] does something similar.
then of course you can always use a [coll] to store all kind of data types, then loadbang a dump command to coll and distribute the data whereever it has to go (for example by a [cycle] or using gates)
if you are firm with using s/r or var/pvar you can sometimes also make use of these for init processes.