Loadbang first in patchers as well as when in bpatchers?


    May 27 2006 | 2:17 pm

    • May 27 2006 | 10:50 pm
      It strikes me as a very bad idea to rely on the order of loadbangs.
      Why do you need to know?
      -- N.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com
    • May 28 2006 | 3:23 am
    • May 28 2006 | 9:59 am
      Well, that's a general argument for modularity. I still don't see why
      you need a semantic model where loadbangs fire from the inside out,
      to an extent where the coding cannot be expressed with loadbangs
      which fire in arbitrary order.
      -- N.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com
    • May 28 2006 | 8:05 pm
    • May 28 2006 | 10:39 pm
      you could have a loadbang>uzi> send load_index (or whatever, but using uzis right most outlet), then each receive load_index can be wired to route 1-20 to express load ordering.....?
      :X
    • May 29 2006 | 10:17 am
    • May 29 2006 | 2:02 pm
      i think it's reliable, but i don't know. If you wan't to be sure you could use a deferlow or delay in the main patch
    • May 29 2006 | 3:37 pm
      I am nearly sure this is completely reliable when dealing with bpatchers.
      With subpatchers, here is an example that works perfectly (OSX): both "last"
      print are printed at the end, and kind of blue is in correct order. As
      everyone here, I still wonder if Max supports that or if I am just lucky
      that it works...
    • May 31 2006 | 10:49 pm
      Sorry if this is a little off topic, but loadbang order can be a concern in different contexts.
      I recently did some testing and found that the loadbang functions inside different js objects fire in the order that the objects appear in the patcher's text file. (i.e. open as text...) I previously thought they fired in chronological order of when the js instance was created, but this isn't always the case.
      How consistent that loadbang order is, and how it relates to loadbang objects in subpatchers, bpatchers, and abstractions I don't know. I bet the order each subpatcher is named in the text file is the answer, though. I try to never use loadbang in subpatchers because it seems like bad style. Style is a subjective thing of course.
      Eric
    • Jun 01 2006 | 5:17 pm
      I do rely on the fact that loadbangs are always performed before patcherargs. Deferring a loadbang to the low priority queue guarantees to be excecuted after all other loadbangs. Maybe this is of any help?
      Greets,
      Mattijs
    • Jun 09 2006 | 5:09 am
      Mattijs Kneppers wrote:
      > I do rely on the fact that loadbangs are always performed before
      > patcherargs.
      This is new to me, I rely on the (official) advice that the order of
      loadbangs/patcherargs is never garanteed...
      If I need a certain order, I use only one loadbang or one patcherargs.
      With a trigger I can create then a garanteed order.
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Jun 09 2006 | 10:54 am
      Is that the official advice? I don't see why loadbang and patcherargs wouldn't be able to have a guaranteed execution order. Anyway, I use around 1000 loadbangs and patcherargs in my current patch and so far the order never failed me :)
      Mattijs
    • Jun 09 2006 | 4:24 pm
      On 9-Jun-2006, at 12:54, Mattijs Kneppers wrote:
      > Is that the official advice? I don't see why loadbang and
      > patcherargs wouldn't be able to have a guaranteed execution order.
      > Anyway, I use around 1000 loadbangs and patcherargs in my current
      > patch and so far the order never failed me :)
      Don't know about official, other than loadbang order is not
      documented. "Not documented" normally means "can change without notice."
      Loadbang order may not have failed you in Max 4.5, but I wouldn't
      rely on it being the same in 4.3, 4.2, 4.1, 4.0, 3.7, 3.5, 2.2 and
      (most importantly) whatever the next version will be.
      But don't let me stop you from living dangerously.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      iCE: Sequencing, Recording & |home | chez nous|
      Interface Building for |bei uns | i nostri|
      Max/MSP Extremely cool http://www.castine.de
    • Jun 09 2006 | 6:33 pm
      Here's a workaround for predictable loading in a subpatch:
      When patcherargs have dumped all atributes it ends of with a @done or
      something like that. If this is used to trigger other settings and the
      attributes put on hold in the meantime (e.g. by means of a coll) if so
      required, you'll have predictable behavior in the patch. But when it
      comes to sequence of triggering between patcherargs in subpatchers and
      parent patchers, I don't know.
      I'm pretty sure I have seen a mail from someone at C74 in the past
      though confirming that loadbang will be fired in subpatchers before the
      top level loadbang is fired.
      Best,
      Trond
      Peter Castine wrote:
      > On 9-Jun-2006, at 12:54, Mattijs Kneppers wrote:
      >
      >> Is that the official advice? I don't see why loadbang and patcherargs
      >> wouldn't be able to have a guaranteed execution order. Anyway, I use
      >> around 1000 loadbangs and patcherargs in my current patch and so far
      >> the order never failed me :)
      >
      > Don't know about official, other than loadbang order is not
      > documented. "Not documented" normally means "can change without notice."
      >
      > Loadbang order may not have failed you in Max 4.5, but I wouldn't rely
      > on it being the same in 4.3, 4.2, 4.1, 4.0, 3.7, 3.5, 2.2 and (most
      > importantly) whatever the next version will be.
      >
      > But don't let me stop you from living dangerously.
    • Jun 09 2006 | 10:37 pm
      Quote: mattijs@samplemadness.nl wrote on Fri, 09 June 2006 03:54
      ----------------------------------------------------
      > Is that the official advice? I don't see why loadbang and patcherargs wouldn't be able to have a guaranteed execution order. Anyway, I use around 1000 loadbangs and patcherargs in my current patch and so far the order never failed me :)
      >
      > Mattijs
      ----------------------------------------------------
      1000 loadbangs?!? =(
    • Jun 09 2006 | 11:00 pm
      Yah man. All my subpatches, and subpatches within subpatches and...have
      loadbangs in them...
      Each abstraction I make has its own loadbang...
      So one simple abstraction that is made up of 5 elementary abstractions will
      have 5 loadbangs.
      One sound processing/producing abstraction may have enough abstractions to
      have 100 loadbangs. My main patch may have 15 sound processing/producing
      abstractions. So I guess I wouldn't think 1000 loadbangs is all that
      weird...
      If I were to go back and rebuild my library of sub-patches I guess I would
      add some sort of receive object to which I could send a global loadbang...
      But then I would still not know the order of execution. (currently I don't
      seem to need this knowledge)
      But if I needed to have o.o.e. control, I would make a loadbang sequence.
      Loadbang
      [t 9 8 7 6 5 4 3 2 1]
      The first number out (1) would initialize the things that needed to be
      initialized first...
      The last number out (9) would initialize the interface to give immediate
      feedback as to the success of the init sequence.
    • Jun 09 2006 | 11:33 pm
      hrm, just seems like a ridiculous amount. I have sluzi connected to a global receiver, and on the receive end, a route for the index of the order, with 20ms delays between each load precedence. Makes for loading the patch much faster.
    • Jun 10 2006 | 12:50 pm
      Quote: langdon wrote on Sat, 10 June 2006 01:00
      ----------------------------------------------------
      > Yah man. All my subpatches, and subpatches within subpatches and...have
      > loadbangs in them...
      Exactly.. for example I use abstractions as wrappers of send/receive objects to add some extra features (such as a remotely assignable voice numbers). Have a look at the mpc2000 patch on the user pages for a simple but slightly outdated example: http://www.cycling74.com/twiki/bin/view/Share/MattijsKnepper s.
      A lot of functional modules in a big patch I am working on depend on these wrapper abstractions for communication with the arbiter part of the patch so the amount of loadbangs easily exceeds 1000. (btw I don't believe avoiding sends en receives is necessary in most cases).
      btw2 the patch itsself easily exceeds 80,000 lines in text form (abstraction code excluded). That is why I am now digging into the dynamic loading of functional modules with [pcontrol]. Anyone has some experience with this? Is that a convenient method to add functionality in 'runtime'? (should I start a new thread? ;)
      Cheers,
      Mattijs
    • Jun 10 2006 | 2:02 pm
      well... my recent main environment is in excess of 10,000 lines as a a text file and only has maybe half a dozen loadbangs.... the patch also loads in under a second.
    • Jun 11 2006 | 2:27 pm
      This loadbang thing probably has much to do with the way I like to create small abstractions that I can trust, just to get it off my mind for the rest of the development process. These small abstractions can be used as often as any other max external and if they contain loadbangs, so be it.
      It's basically just OO programming, I like to be able to extend the functionality of these small 'methods' without having to go through the entire patch to search for all occurrences. In other words I like to use abstractions, but..
      ..but only when a small functionality is needed often in a lot of [i]different[/i] situations. Otherwise I stick to a series of subpatchers together with my big friend 'paste replace' because a) debugging is much easier and b) abstractions still can't be stored in a subdir of the main patch dir (and I am definitly not going to put my project directories in max' patchers folder, of all places)..
    • Jun 11 2006 | 2:31 pm
      Quote: binez0r wrote on Sat, 10 June 2006 16:02
      ----------------------------------------------------
      > well... my recent main environment is in excess of 10,000 lines as a a text file and only has maybe half a dozen loadbangs.... the patch also loads in under a second.
      ----------------------------------------------------
      Hm, mine takes more than a minute on a dual G5 (or quad, almost alike).. Does that mean the amont of (small) abstractions is important for the load time? How many abstraction instances does your patch contain?
    • Jun 11 2006 | 5:08 pm
      I have a patch that can have a dynamic number of abstractions in it,
      all scripted with thispatcher, and Ive found the largest thing with
      loadtime for my system is the fact that I use JSUI objects. If I
      remove them, the patch loads *much* faster.
      None of the abstractions have loadbangs in them... My patch also
      takes about a minute or so on a 1.67 G4 with all the abstractions
      loaded. With only a select few its like 10 seconds.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Jun 12 2006 | 6:54 am
      Trond Lossius wrote:
      > I'm pretty sure I have seen a mail from someone at C74 in the past
      > though confirming that loadbang will be fired in subpatchers before the
      > top level loadbang is fired.
      It was pretty recent and it seems to be the case as I recall, which
      makes a lot of sense...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com