Why Are My Loadbangs Not Banging?

Dec 4, 2008 at 5:10pm

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?

#41190
Dec 4, 2008 at 5:18pm

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

#146457
Dec 4, 2008 at 5:27pm

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.

#146458
Dec 4, 2008 at 5:44pm

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.

– Pasted Max Patch, click to expand. –
#146459
Dec 4, 2008 at 5:51pm

Arne, that idea is as simpel as beautiful.

thanx for that,

jrp

#146460
Dec 4, 2008 at 6:08pm

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

#146461
Dec 4, 2008 at 6:29pm

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…

#146462
Dec 4, 2008 at 7:02pm

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

#146463
Dec 4, 2008 at 7:04pm

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

#146464
Dec 4, 2008 at 7:23pm

#146465
Dec 5, 2008 at 1:43am

wie genau sieht der bug aus, stefan?

jrp

#146466
Dec 5, 2008 at 1:57am

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.

#146467
Dec 5, 2008 at 8:12am

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.

– Pasted Max Patch, click to expand. –

_
johan

#146468

You must be logged in to reply to this topic.