loadbang call order

    May 18 2013 | 4:37 pm
    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 | 4:42 pm
      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.
    • May 18 2013 | 4:47 pm
      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 | 5:37 pm
      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/
    • May 18 2013 | 5:48 pm
      great stuff - was just doing something similar myself - glad to know that I'm not missing something simpler.... :)
    • May 19 2013 | 3:44 pm
      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]
    • May 19 2013 | 4:30 pm
      One way to control the order commands are sent is to use qlist.