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.
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?
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 :)
> 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 :)
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.
> 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? ;)
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)..
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?