Why Are My Loadbangs Not Banging?
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?
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.
hope that helps,
jrp
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.
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].
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
initialize message to other patchers.
Arne, that idea is as simpel as beautiful.
thanx for that,
jrp
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].
That's still not deterministic, is it?
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.
-C
Chris Muir
cbm@well.com
http://www.xfade.com
2008/12/4 Chris Muir :
> That's still not deterministic, is it?
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:
> 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.
- C
Chris Muir
cbm@well.com
http://www.xfade.com
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
wie genau sieht der bug aus, stefan?
jrp
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
>
>
----------------------------------------------------
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.
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.
_
johan