Andy

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.

1 One loadbang filtered through all sub patches

2 A loadbang object for every element that requires it

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

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

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

best-use-of-loadbang

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

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

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

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

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

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

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. 

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.  

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.

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.

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.

Quote: swieser1 wrote on Thu, 24 May 2007 18:15

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

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.

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. 

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

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.

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

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

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


> 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 

Other aspects are 'elegance', 'clearness', 'comprehensibility'...

And of course in one context it might work and in another it doesn't, 

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 

You can draw a flow chart, actually my flow charts are Max patches, they 

If there are no information dependencies, just don't bother and keep it 

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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:

(note - this is only a prototype; it works, but don't use it)

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.

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)

> i've never seen a loadbang not fire....

you will see that when you have a patch with lots of

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

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

> 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

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.

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

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.

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

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. 

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

otherwise sending loadbangs from outside would be the same

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.

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.


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

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

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

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.

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


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

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

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

Quote: Stefan Tiedje wrote on Mon, 28 May 2007 07:37

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

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.

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

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


Best use of loadbang