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,
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.
----------begin_max5_patcher---------- 657.3oc6W0ziaBCD8L7q.4yoq.Rxpj9CoWhphLvjrt0XifgzztZ+uWiMjXSf z7QaOwEHLyX627lmmQ4ceORh7HTQB9bvl.Ou2887zlZL309sGImdLkSqzgQD vOjIeiLy3Bgin1bU.SvPFky9Ez4TTmKqQNf5UF1ZcmTfUMQorEE8Rm4BJl9F SreaIjhF.EsXoxcPzR8qW0OiCeIL3qsqgkoOaEd9zRh01Kn45sm7EnLiJnV. hI5vSTisO78adL64R9Bqje6AJuVQoCxAQOLGDadEt9BRvr83OK.yJHITwdxP bz76mirAFT1xLsTiZeXb3.TVwjBqn8Hmg+53F7tdgt.tHr40hUVnWQ364xzu CYVRDORFr6d1CYAHNGuNBmGtQxDEkPEHPJ1Bb6ykVywsCWeb8uilBit3QXWO x9RVlTz.Cm01Xt6.2Dnq0Ksws1ufVLvRQojmPKOvpXIbvoNnDyTAKmh.xL3I N7z5X4EkLA5rW4.RynH0.CqhjcWBKEfyEFG68t3XDocrvnMGF6VvJi52T7MW Ehs4mdB83dGzEBZsiTYdNXH.Boyrtgf4GydvbUeZimpQ2Rp950xzqeiuOYDM JYDdGjwYs.mIFSKnSmF+CyRUx5xzNL2Bs.2TKCpPl3zEyMmpm8h6MVVl68.c YfkUHUZ5pN86fIhea40zZqhd.x1pNEUEXKEwRVRMZRPmVcCci+gZSn52kP4s cTO0mfbWcQtpywZh4elI9GL1KUx4+sm5s17b0SLyKdZl2zLuoYdSy7ll4MMy 6dl4oXDTUPt5.swmb0pkCehIWQ+w+0pdUtZSSl0WS1leWnEmaqwFQGtzIlKz fCq+tfquUDEeCHZ9+UDEcCHJ9IPj5iO7+MPsijN3 -----------end_max5_patcher-----------
Arne, that idea is as simpel as beautiful.
thanx for that,
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.
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
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
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.
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.
wie genau sieht der bug aus, stefan?
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.
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.
----------begin_max5_patcher---------- 407.3ocuT10aBBCEF9Z3WQSuFMT918CY2rXVJzp1En0.knaF+uO3.DGSTwIy aZSO8zSeee5GGLMvwp87BL5EzaHCiClFFPn5.FsiMvYz8IozBHMbboVqjXql oTk5TtV+4VdSMvwT4ZLZY6zxxLgrJAXoj1fBFTHU7GyB6pyVpNYiPt98bdht oTttAyssPNQQPmcW6OKdy12T85fGMMqarFoWj7cUpnSCZ9dXqwE7Tj80cnEB exkqTRcg3KHABoRmCXdmyMu+HLuCXd2vyLe8dJoYvdhekmynRJdPv3LcfYFh bQrHj5GlHdWiHAM2.7c.h3L2+OSjI7pBiuhmmp1cQrbeLYfmHti3VhsWcmez CbKYBYRphxx3EEHhs8+GWH2lKj.fHQgSDWfkiSExe+iIHg538gUgpLOoyvsu 3QmDAiWnERpVT8c5obB6kyFAiwgo63RlfsUU8XqUBnkCdvMVE4MBE4deJxMX A71LDvtmsOP+diHKfyGWO+5LgQOnOpIK4F9v6oRV2QPV+mphHS+YcOEUM3n4 2v4TkyO -----------end_max5_patcher-----------