Best use of loadbang

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.

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

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.

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

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

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

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

1st cent:

consider this:

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