– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

:X

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 106 172 52 196617 print last;
#P newex 106 129 48 196617 loadbang;
#N vpatcher 10 59 610 459;
#P window setfont “Sans Serif” 9.;
#P newex 76 57 48 196617 loadbang;
#P newex 76 81 59 196617 print trane;
#P connect 1 0 0 0;
#P pop;
#P newobj 114 87 42 196617 p trane;
#N vpatcher 10 59 610 459;
#P window setfont “Sans Serif” 9.;
#P newex 76 57 48 196617 loadbang;
#P newex 76 81 48 196617 print col;
#P connect 1 0 0 0;
#P pop;
#P newobj 53 88 31 196617 p col;
#P newex 51 172 52 196617 print last;
#P newex 51 129 48 196617 loadbang;
#N vpatcher 20 74 620 474;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 138 95 48 196617 loadbang;
#P window linecount 0;
#P newex 138 114 53 196617 print blue;
#N vpatcher 169 163 769 563;
#P window setfont “Sans Serif” 9.;
#N vpatcher 40 104 640 504;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 52 45 48 196617 loadbang;
#P window linecount 0;
#P newex 52 66 53 196617 print kind;
#P connect 1 0 0 0;
#P pop;
#P newobj 64 60 36 196617 p kind;
#P newex 114 82 44 196617 print of;
#P newex 114 61 48 196617 loadbang;
#P connect 0 0 1 0;
#P pop;
#P newobj 69 110 25 196617 p of;
#P connect 2 0 1 0;
#P pop;
#P newobj 54 51 36 196617 p blue;
#P connect 5 0 6 0;
#P connect 1 0 2 0;
#P window clipboard copycount 7;

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

Greets,
Mattijs

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

Mattijs

> 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

http://www.dspaudio.com/

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.

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.

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. < == don't forget the s (<-forum bug)

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

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?

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 //

http://www.vade.info
abstrakt.vade.info