Hi, if I have a patcher with severnal subpatchers, is there a guaranteed order to the loadbang calls? i.e., does the loadbang of the patcher get called before any of the subpatchers?

loadbang-call-order

subpatchers are first (so that you can initialise them from outside), and otherwise it is right to left, bottom to top, like everything.

but i´d recommend to control the order yourself anyway, everywhere, it is just safer.

subpatchers are first (so that you can initialise them from outside), and otherwise it is right to left, bottom to top, like everything.
but i´d recommend to control the order yourself anyway, everywhere, it is just safer.

couple of things, how would you control the order yourself (other than via positioning)

i was hoping to create a unique name when the patcher loads and store it so that subpatchers can use it for send/recieve comms - sounds like I#d have to do this in a specific subpatcher and make sure this fires first rather than to it in the main patcher?

If your patch is largish, it's probably better to take control of the order of initialization yourself. In this thread I discuss the method I'm using:

https://cycling74.com/forums/patch-veeery-slow-to-behave-smoothly/

If your patch is largish, it's probably better to take control of the order of initialization yourself. In this thread I discuss the method I'm using:
https://cycling74.com/forums/patch-veeery-slow-to-behave-smoothly/


great stuff - was just doing something similar myself - glad to know that I'm not missing something simpler.... :)

there are two main strategies to control the order.

avoid that controlling the order is necessary.

build your abstractions and subpatches always so they have a useful init status, then let the parent level control its parameters via arguments and/or inlets.

where order is still needed, use right to left order.

[object4] [object3] [subpatcher2] [subpatcher1]

i think you find out that you almost never need to control the order when your subpatchers and abstractions are organized nicely. where you do, a simple t b b and a connection makes sure what is banged first.

one possible alternative is to use abstractions inside abstractions instead of [loadbang].

[myloadbang] could, for example, contain a [loadbang] which is only passing a [gate] when a certain number is received via a [receive] object. or you can use just a [select] object.

inside the [myloadbang] abstraction you would have something like this:

in the parent level you will do nothing more than:

[loadbang]-[uzi 25](second outlet)-[forward myloadbang]

1.)
avoid that controlling the order is necessary.
build your abstractions and subpatches always so they have a useful init status, then let the parent level control its parameters via arguments and/or inlets.

root level:
[loadbang]-[500.]-[myfilter 200.]

2.)
where order is still needed, use right to left order.

root level:
[loadbang]
[t b b b b]
[500.] [600.] [700.] [800.]
[object4] [object3] [subpatcher2] [subpatcher1]

inside the [myloadbang] abstraction you would have something like this:
[recieve myloadbang]-[select #1]

in the parent level you will do nothing more than:
[loadbang]-[uzi 25](second outlet)-[forward myloadbang]

One way to control the order commands are sent is to use qlist.

Can anyone confirm that loadbang order is:

I would guess that the right to left, bottom to top order would apply to all abstractions and encapsulated patchers but it seems to not be working that way on my end. Encapsulated patch is always fired before the abstraction.

(is there an official documentation place explaining this that I forgot/miss?)

Can anyone confirm that loadbang order is:
-first encapsulated patchers
-then abstractions
-and only then parent patch
?
I would guess that the right to left, bottom to top order would apply to all abstractions and encapsulated patchers but it seems to not be working that way on my end. Encapsulated patch is always fired before the abstraction.
(is there an official documentation place explaining this that I forgot/miss?)

no difference between the different kind of subpatchers, including bpatcher patches.

actually what I am getting right now, among subpatchers, is order of creation!... their location in the parent patch is completely ignored.

regardless of how I moved them around I always get printed: first, second, third, fourth, and parent.

actually what I am getting right now, among subpatchers, is order of creation!... their location in the parent patch is completely ignored.



regardless of how I moved them around I always get printed: first, second, third, fourth, and parent.

you are right, i just tried it in max 4 and came to the same result, for [p] it is order of creation.


you are right, i just tried it in max 4 and came to the same result, for [p] it is order of creation.

or in other words: better forget [p]


loadbang call order