Loadbang first in patchers as well as when in bpatchers?

May 27, 2006 at 2:17pm

Loadbang first in patchers as well as when in bpatchers?

#26185
May 27, 2006 at 10:50pm

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://
http://www.cassiel.com

#77877
May 28, 2006 at 3:23am

#77878
May 28, 2006 at 9:59am

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://
http://www.cassiel.com

#77879
May 28, 2006 at 6:16pm

#77880
May 28, 2006 at 8:05pm

#77881
May 28, 2006 at 10:39pm

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

#77882
May 29, 2006 at 9:58am

#77883
May 29, 2006 at 10:17am

#77884
May 29, 2006 at 2:02pm

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

#77885
May 29, 2006 at 3:37pm

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…

#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;

#77886
May 31, 2006 at 10:49pm

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

#77887
Jun 1, 2006 at 5:17pm

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

#77888
Jun 9, 2006 at 5:09am

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

#77889
Jun 9, 2006 at 10:54am

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

#77890
Jun 9, 2006 at 4:24pm

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

http://www.dspaudio.com/

#77891
Jun 9, 2006 at 6:33pm

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.

#77892
Jun 9, 2006 at 10:37pm

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?!? =(

#77893
Jun 9, 2006 at 11:00pm

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.

#77894
Jun 9, 2006 at 11:33pm

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.

#77895
Jun 10, 2006 at 12:50pm

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

#77896
Jun 10, 2006 at 2:02pm

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.

#77897
Jun 11, 2006 at 2:27pm

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

#77898
Jun 11, 2006 at 2:31pm

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?

#77899
Jun 11, 2006 at 5:08pm

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

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

#77900
Jun 12, 2006 at 6:54am

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

#77901

You must be logged in to reply to this topic.