ComfortableInClouds

If you open the "NoteGenerator.pat" file that is attached, you'll see I have a loadbang connected to several messages. Now, if you open the same patch as a bpatcher, this loadbang doesn't send out a bang, since the messages aren't being displayed. What's going on here?

why-are-my-loadbangs-not-banging

i half-recall something like this might be a bug. however, as something to be tested or even a workaround, make an inlet to your bpatcher patch, and send loadbang from main patch.

it seems silly to me that i have to create 6 separate inlets for a patch that's only supposed to require 1.

plus, i just realized that even when opening the NoteGenerator.pat as a patch and not a bpatcher, the loadbang still does not work.

i am getting this same bug also in Max 5.05.

plus, i just realized that even when opening the NoteGenerator.pat as a patch and not a bpatcher, the loadbang still does not work. 

i am getting this same bug also in Max 5.05.


I personally do not trust loadbangs, since there is no way to

determine the order of firing with multiple subpatchers/bpatchers.

Instead, I want to control initialization. For any patch that needs an

Then in the main patch, I have a [s initialize].

If I need more control, I will have a separate patcher to

initialize/fill my colls, one to initialize my values, then send the

I personally do not trust loadbangs, since there is no way to
determine the order of firing with multiple subpatchers/bpatchers.

Instead, I want to control initialization. For any patch that needs an
initialization, I have a [r initialize].

If I need more control, I will have a separate patcher to
initialize/fill my colls, one to initialize my values, then send the
initialize message to other patchers.

Arne, that idea is as simpel as beautiful.

On Dec 4, 2008, at 9:44 AM, Arne Eigenfeldt wrote:

> Instead, I want to control initialization. For any patch that needs an

> initialization, I have a [r initialize].

> Then in the main patch, I have a [s initialize].

In my biggest patch, I adopted a scheme that works pretty well for me. 

In the upper left corner of my top-level patch, I have an sub-patcher 

that receives a loadbang, and starts a process of counting to 100, 

driven by a metro. I distribute this value via [s LoadPercent]. Then 

in all my abstractions, bpatchers, and subpatchers, I have an [r 

LoadPercent] and fire off my local initialization when the LoadPercent 

This way I can determine the order in which things get initialized, 

It adds a little time to my startup, but everything always starts up 

On Dec 4, 2008, at 9:44 AM, Arne Eigenfeldt wrote:
> Instead, I want to control initialization. For any patch that needs an
> initialization, I have a [r initialize].
>
> Then in the main patch, I have a [s initialize].

In my biggest patch, I adopted a scheme that works pretty well for me.  
In the upper left corner of my top-level patch, I have an sub-patcher  
that receives a loadbang, and starts a process of counting to 100,  
driven by a metro. I distribute this value via [s LoadPercent]. Then  
in all my abstractions, bpatchers, and subpatchers, I have an [r  
LoadPercent] and fire off my local initialization when the LoadPercent  
exceeds some threshold.

This way I can determine the order in which things get initialized,  
across a giant, sprawling, patch.

It adds a little time to my startup, but everything always starts up  
in the proper order.

Chris Muir
cbm@well.com	
http://www.xfade.com

If order needs to be controlled *across* patches, then I think there

might be a conceptual problem. At least that is the case in my

If subpatcher A relies on the data of subpatcher B, then the data in A

is global, rather than local, and should be treated as such. I put

global data within the main patch, and initialize it first, before

I strongly believe in maintaining a structured programming approach,

in which inputs and outputs to all patchers and subpatchers are

But, as I like to point out, I don't have a degree in computer science...

If order needs to be controlled *across* patches, then I think there
might be a conceptual problem. At least that is the case in my
patching.

If subpatcher A relies on the data of subpatcher B, then the data in A
is global, rather than local, and should be treated as such. I put
global data within the main patch, and initialize it first, before
sending out local initializations.

I strongly believe in maintaining a structured programming approach,
in which inputs and outputs to all patchers and subpatchers are
tightly controlled.

But, as I like to point out, I don't have a degree in computer science...


On Dec 4, 2008, at 10:29 AM, Arne Eigenfeldt wrote:

> global data within the main patch, and initialize it first, before

Right, but the order of receive is itself not deterministic. When you 

[s initialize], the order that the various [r initialize] objects get 

> I put
> global data within the main patch, and initialize it first, before
> sending out local initializations.

Right, but the order of receive is itself not deterministic. When you  
[s initialize], the order that the various [r initialize] objects get  
the message is undetermined.

If you put some print objects in your patches I believe you'd find that the loadbang objects work just fine.

The reason it appears as if your loadbang objects aren't working is that you have an autopattr in the bpatcher's patcher (NoteGenerator.pat) which initializes the number box values *after* the loadbang fires. Remove that autopattr and you will see the loadbang works fine.

If you put some print objects in your patches I believe you'd find that the loadbang objects work just fine.  

The reason it appears as if your loadbang objects aren't working is that you have an autopattr in the bpatcher's patcher (NoteGenerator.pat) which initializes the number box values *after* the loadbang fires.  Remove that autopattr and you will see the loadbang works fine. 

Quote: Rob Sussman wrote on Thu, 04 December 2008 14:04

----------------------------------------------------

> If you put some print objects in your patches I believe you'd find that the loadbang objects work just fine. 

> The reason it appears as if your loadbang objects aren't working is that you have an autopattr in the bpatcher's patcher (NoteGenerator.pat) which initializes the number box values *after* the loadbang fires. Remove that autopattr and you will see the loadbang works fine. 

thanks rob. added a [delay 1000] after the loadbang and now everything is fine.

these other systems seem interesting, but are certainly a bit beyond my simple patch. ill keep them in mind for future projects tho.

Quote: Rob Sussman wrote on Thu, 04 December 2008 14:04
----------------------------------------------------
> If you put some print objects in your patches I believe you'd find that the loadbang objects work just fine.  
>
> The reason it appears as if your loadbang objects aren't working is that you have an autopattr in the bpatcher's patcher (NoteGenerator.pat) which initializes the number box values *after* the loadbang fires.  Remove that autopattr and you will see the loadbang works fine. 
>
> Rob
>
>
----------------------------------------------------

these other systems seem interesting, but are certainly a bit beyond my simple patch. ill keep them in mind for future projects tho.


And sometimes deferringlow wit [deferlow] is unavoidable. Loadbangs in my patches can be grouped according to two types of behavior, one group that simply initializes attributes to objects (where the @ is not supported yet) and another group that initializes behavior of the patch. In order to have the latter waiting for the first, recently I thought of the patch below. I'm going to extend and incorporate Chris Muir's idea.

Why Are My Loadbangs Not Banging?