Best use of loadbang

May 24, 2007 at 10:15pm

Best use of loadbang

Hi,
I’m unsure of the science behind this so maybe someone would be able to shed some light on this for me.

Basically what I am trying to discern is how best to use loadbangs. I ask this question as I have noticed that loadbangs can occasionally stop working in the big patch scenario.

What would be the best method to use:

1 One loadbang filtered through all sub patches
2 A loadbang object for every element that requires it
3 Some other method entirely

and would this method change due to the nature/size of the project?

Does anybody have any comment?

Cheers

Andy

#32089
May 24, 2007 at 11:32pm

1 One loadbang filtered through all sub patches

- This approach gives you control over the order in which the bangs are sent to each object or subpatch. It is, however, more labor intensive to set your patch up this way. With good organization, it can be done with a minimum of effort.

2 A loadbang object for every element that requires it

- This approach is much easier to implement (i.e. just throw a loadbang in wherever you need it). However, there is no guarantee that the bangs will come out in a certain order, and furthermore there is no guarantee that it will happen the same time everytime you load the patch. So, if the order of the loadbangs doesn’t matter, then this would probably be the way to go.

3 Some other method entirely

- It really depends on what your patch requires. I’ve made some patches that were so big that the loadbangs would bog down the loading of the patch to the point where it would hang indefinitely. In these cases, you might have to put a delay object after some of the loadbangs, so that you do your initialization in phases.

#105054
May 24, 2007 at 11:49pm

To be honest I’m pretty much used to using one load bang and threading anyway as it makes sense to have control over loadbang ordering, but just recently I have been lazy by using the one load bang per requirement approach.

I haven’t personally noticed any difference between the 2 methods in terms of accuracy (probably because I hadn’t been looking for a difference), but am unsure if there is a scientifically ‘correct’ approach.

I have occassionally had problems with loadbangs not banging in large patches (which is what prompted the question). Usually a delay on the problem loadbang does do the trick but just recently I created a patch with a loadbang that would just not bang. Even with a delay and an uzi after it.

Besides which in the threaded/ordered scenario each bang originates from the same call.

Essentially what I am getting at here is – Is there a definitive method to ensure that a loadbang will work 100% of the time.

Cheers

Andy

#105055
May 25, 2007 at 12:15am

i’ve never seen a loadbang not fire…. if you can build a patch with a loadbang that will not fire, i think you should post it as a bug.

to be frank, i’d be more suspicious that the stuff you have your loadbang connected to is not working. try connecting the malfunctioning loadbang object to a print object and check the max window at startup. if you don’t get a “print: bang” in the max window, then you should submit a bug report. otherwise, there’s something wrong with your programming.

as far as the “scientifically correct” way to initialize your patch, my opinion is that it is too dependent on the structure and requirements of your patch to come up with a generalized statement.

#105056
May 25, 2007 at 1:04am

Quote: swieser1 wrote on Fri, 25 May 2007 02:15
—————————————————-
> i’ve never seen a loadbang not fire…. if you can build a patch with a loadbang that will not fire, i think you should post it as a bug.

Since I think the first max version that was universal binary I have noticed this as well. My theory is that loadbang can now fire before the part of the patch that it connects to has instantiated. Recently I have been using deferlow almost as a standard practice, it should probably be built in. Anyhow, loadbangs go everywhere as long as atributes remain a jitter thing.

_
johan

#105057
May 25, 2007 at 1:54am

Quote: swieser1 wrote on Thu, 24 May 2007 18:15
—————————————————-
> i’ve never seen a loadbang not fire…. if you can build a patch with a loadbang that will not fire, i think you should post it as a bug.
>

I’m not particularly suggesting that the loadbang is not firing. What I am suggesting is that the bang is not reaching the subsequent objects – and only occurs on big patches.

There is certainly nothing in the programming to stop the loadbang from working – the most recent instance of this problem occured with the simple ordered banging of a Jit.qtmovie object to create a texture to apply to a slab – not much margin for error (and delays of various lengths were tested).

Although…..
I have not tried printing on this patch yet yet so will give that a go to see what happens.

In regards to the correct way of using bangs, I appreciate the fact that every patch is different amd hence has different requirements so a generalised answer cannot be given, but what are the factors and what sort of things can be put in place? Are we talking about system optimisation settings here or simply using one loadbang with a delay to avoid (as suggested by Johan) a loadbang reaching an object before it is instantiated.

Cheers

Andy

#105058
May 25, 2007 at 3:10am

At 4:16 PM -0600 5/24/07, Andy Brennan wrote:
>Basically what I am trying to discern is how best to use loadbangs. I ask this question as I have noticed that loadbangs can occasionally stop working in the big patch scenario.

What I ended up going for in Gyre, a fairly large sequencer-ish program I’m writing, is a secondary loadbang. I mostly have loadbangs where I need them, but for some thing that relies on stuff being more or less setup, I have a secondary loadbang. This takes the form of a longish delay on a bang from a normal loadbang being sent through a “s SecondaryLoadbang”.

I put “r SecondaryLoadbang” where I need them for some of the more critical stuff. I have a few smallish delays on some of the secondary loadbang things, so that I can control the order that they are executed.

Since I went to this two-tier loading scheme, things have been really smooth.

-C

p.s.
Gyre info, if anyone’s interested:

http://www.xfade.com/Gyre


Chris Muir | “There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue.” – Brian Eno

#105059
May 25, 2007 at 8:54am

Andy Brennan schrieb:
> but am unsure if there is a scientifically ‘correct’ approach.

As you probably have seen, there a a zillion ways to find a solution for
a given problem. If you are only concerned about scientific
‘correctness’, its that: If it works, its correct. Absolute no matter
how you do it…
Other aspects are ‘elegance’, ‘clearness’, ‘comprehensibility’…

And of course in one context it might work and in another it doesn’t,
then you have to investigate again.
In my experience elegance is a good bet to have less problems later…

I think in terms of information flow. How are the dependencies of
information.
You can draw a flow chart, actually my flow charts are Max patches, they
work immediately.. ;-)
If there are no information dependencies, just don’t bother and keep it
simple. (loadbang it…)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#105060
May 25, 2007 at 10:21am

#105061
May 25, 2007 at 11:04am

1st cent:

consider this:
#N vpatcher 50 119 261 359;
#P newex 67 127 63 196617 route inside;
#P newex 50 168 32 196617 print;
#P newex 70 71 50 196617 deferlow;
#P newex 69 50 48 196617 loadbang;
#P newex 50 147 27 196617 f;
#P newex 67 107 64 196617 patcherargs;
#P connect 2 0 1 0;
#P connect 3 0 1 0;
#P connect 1 0 4 0;
#P connect 0 0 5 0;
#P connect 5 0 1 1;
#P connect 2 0 3 0;
#P pop;
#P newobj 59 59 68 196617 p inside 1.62;

patcherargs always fires after loadbang. This might cause confusion, especially in bigger patchers. Loading order in max is not yet very mature.

I think what you need ideally is an object with an argument that determines when it fires. Here is a possible approach:

http://www.arttech.nl/TS.loadbang.zip
(note – this is only a prototype; it works, but don’t use it)

2nd cent:

Furthermore I must disagree with stefan on the ‘if it works, it’s correct’ statement. It’s -very- important to design your patch carefully and structured. If you don’t, you’ll never be able to make bigger patches than what you can learn by heart, which is not much.

My 2 cents,
Mattijs

#105062
May 25, 2007 at 5:11pm

Quote: swieser1 wrote on Thu, 24 May 2007 18:15
—————————————————-
> i’ve never seen a loadbang not fire….

you will see that when you have a patch with lots of
lcd messages, menu-filling, or uzis.
and also the slower a computer is, the earlier runs
into trouble with too much tasks going on.

after it happened the second time one of my projects
could no longer be opened or banged, i started switching
to dependency mode: my subpatcher do no longer have
loadbangs at all – they now only have an inlet called “loadbang”.

-110

#105063
May 25, 2007 at 5:26pm

> Basically what I am trying to discern is how best to use loadbangs. I ask this question as I have noticed that loadbangs can occasionally stop working in the big patch scenario.
>

> 1 One loadbang filtered through all sub patches
> 2 A loadbang object for every element that requires it
> 3 Some other method entirely
>

Just for information, I find it best to use only one loadbang, that fires through a button into a send object called “send init.” (This is IRCAM-style, I believe). In very complex situations, I have a loadbang that drives a counter through “init” so I can have things that fire off in a a particular order.

One reason for this is that a loadbang in an instance of an abstraction does not fire when the abstraction file is edited and saved. This can be a great source of confusion while editing a large patch. It makes my life much simpler if I impose a discipline that means I can click one button and have my patch be in the state it was in when it loaded. Also, this can be very helpful in rehearsals, where every second counts.

This method is what I would call “old skool.” I am also integrating the world of “pattr” into my state management techniques.

mz

#105064
May 25, 2007 at 7:54pm

Quote: mzed wrote on Fri, 25 May 2007 19:26
—————————————————-
> Also, this can be very helpful in rehearsals, where every second counts.

This is the reason why I prefer -not- to have one loadbang that triggers everything. In my patches, mostly a lot of systems run simulateously and while reheasing I want to change one abstraction, save it and have it init itself, without resetting the state of all other systems, so that the jam can continue without interruption apart from the functionality of the abstraction.

That’s why I would prefer to use patcherargs, the only problem is that patcherargs doesn’t have a clearly defined load order (psst.. for insiders, patcherargs does have a defined load order only it’s not officially supported. The one you entered last fires first. But of course I don’t want to make my patch dependent on the order in which I inserted the objects).

Mattijs

#105065
May 25, 2007 at 9:51pm

#105066
May 25, 2007 at 10:51pm

Quote: jeanfrancois.charles wrote on Fri, 25 May 2007 15:51
—————————————————-
> > Just for information, I find it best to use only one loadbang, that fires
> > through a button into a send object called “send init.”
> In that case, the order in which loadbangs are received is not guaranteed.

thats true, only an inlet give you that option, not sends.

i forgot to add that in my post above: of course i am
using 1. delays for different subpatches and 2. organize
order of bangs by triggers.
otherwise sending loadbangs from outside would be the same
than having them in each subpatch.

#105067
May 25, 2007 at 11:24pm

> 3 Some other method entirely

Another possibility, if ordering isn’t so important (although you can
integrate this with an ordering scheme using selectively placed
loadbangs, if it is, or with trigger objects, which might make the most
sense): what about pattrstorage? That sets values simply and without
much trouble (i.e. setting loadbangs or passing into subpatches or sends
& receives, etc.) especially if you are using autopattr (w/autoname = 1).

I use this all the time, and sparingly use loadbangs. Not only does
this give you an easy way to set and save values–just set objects to
the value you want, and store–but it allows for multiple setting
configurations, and requires less debugging (in my experience). The
only loadbang/loadmess you’ll need is the one to hit the recall message
for the setting you want to run when the patch loads.

I recognize this might not always be the best or right solution, it’s
just something to consider.

Best,
Dave

Andy Brennan wrote:
> Hi,
> I’m unsure of the science behind this so maybe someone would be able to shed some light on this for me.
>
> Basically what I am trying to discern is how best to use loadbangs. I ask this question as I have noticed that loadbangs can occasionally stop working in the big patch scenario.
>
> What would be the best method to use:
>
> 1 One loadbang filtered through all sub patches
> 2 A loadbang object for every element that requires it
> 3 Some other method entirely
>
> and would this method change due to the nature/size of the project?
>
> Does anybody have any comment?
>
> Cheers
>
> Andy

#105068
May 27, 2007 at 1:03pm

Mattijs Kneppers schrieb:
> 1st cent:
>
> consider this:

2nd cent:

better do it like this:

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#N vpatcher 264 168 475 408;
#P window setfont “Sans Serif” 9.;
#P newex 121 101 62 196617 route done;
#P newex 67 127 63 196617 route inside;
#P newex 50 168 32 196617 print;
#P newex 50 147 27 196617 f;
#P newex 67 80 64 196617 patcherargs;
#P fasten 4 0 1 0 126 121 55 121;
#P connect 1 0 2 0;
#P connect 0 0 3 0;
#P connect 3 0 1 1;
#P connect 0 1 4 0;
#P pop;
#P newobj 59 59 68 196617 p inside 1.62;
#P window clipboard copytext “p inside 1.62″ #E;
#P window clipboard copycount 1;


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#105069
May 28, 2007 at 5:37am

Mattijs Kneppers schrieb:
> That’s why I would prefer to use patcherargs, the only problem is
> that patcherargs doesn’t have a clearly defined load order

Which is not a problem if you restrict yourself to one single
patcherargs object per patcher, which is never a problem…
Within one patcher you can always get a correct order of events…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#105070
May 28, 2007 at 7:03pm

Quote: Stefan Tiedje wrote on Mon, 28 May 2007 07:37
—————————————————-
> Mattijs Kneppers schrieb:
> > That’s why I would prefer to use patcherargs, the only problem is
> > that patcherargs doesn’t have a clearly defined load order
>
> Which is not a problem if you restrict yourself to one single
> patcherargs object per patcher, which is never a problem…
> Within one patcher you can always get a correct order of events…
>
> Stefan

I’m afraid that’s not true. If I need several abstractions to interact on load, I need them to be initialized in a predefined order.

Mattijs

>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>
—————————————————-

#105071

You must be logged in to reply to this topic.