Forums > MaxMSP

loadbang call order


Lee
May 18, 2013 | 9:37 am

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?

thx Lee


May 18, 2013 | 9:42 am

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.

-110



Lee
May 18, 2013 | 9:47 am

thx… useful to know

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?


May 18, 2013 | 10:37 am

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:

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



Lee
May 18, 2013 | 10:48 am

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


May 19, 2013 | 8:44 am

there are two main strategies to control the order.

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

subpatcher:
[loadbang]-[f #1]-

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]

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

subpatcher:
[myloadbang 5]-

[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:
[recieve myloadbang]-[select #1]

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

-110


May 19, 2013 | 9:30 am

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


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