[PD] initbang/closebang and $@ patch statuses

Mathieu Bouchard matju at artengine.ca
Sun Jun 20 03:28:03 CEST 2010

On Sat, 19 Jun 2010, Jonathan Wilkes wrote:

>  2009-03-14, quoting Miller: "Anyhow, I'm trying to think of a better 
> mechanism for allowing abstractions to have variable numbers of 
> inlets/outlets, so I'm hoping initbang won't be necessary in the long 
> run."

If he were really trying, he would have found something or would have 
asked for advice. But no.

There's also a problem with always waiting for the best solution at the 
expense of finding a solution at all, NOW, or five years ago.

> I'd like to ask: what is the problem with [initbang] as it is, and what would
> a "better mechanism" look like?

Whatever it is, it can't be supporting variable number of signals. What I 
thought about, is that you could have a [inlets] just like GF's [receives] 
that does multiple-receive. You first get the receive-symbol from the 
right outlet, the actual content from the left outlet. For [inlets] it 
would be the same, except you get an inlet-number out of the right-outlet. 
It's the only way you can do it without dynamic-patching. That's a cool 
solution, but it also doesn't support signals at all.

Thus you still need [initbang] and dynamic patching.

Are there any other reasons to use [initbang] ? I can't think of any, but 
I have the impression that I'm forgetting about something.

Well, actually, you can send to a toplevel iemgui's receive-symbol at 
loadbang-time, but you can send to an abstraction's receive-symbol at 
loadbang-time ONLY WHEN the receive-symbol is not computed at 
loadbang-time. Else the loadbang-order will not be reliable.

It took me a while to think of that one, but it makes me believe that we'd 
eventually hit limitations and have to do weird workarounds because of 
those limitations if there's no [initbang], for things not related to 
variable number of inlets.

> If a "better mechanism" is not currently in the works, could these two 
> objects be included in pd-vanilla so that in the meantime people can 
> make abstractions that have dynamic numbers of inlets/outlets that will 
> work on both versions of pd?

do you have Miller's phone number ?

> (I've never used [closebang] but I imagine the same reasoning holds for 
> it as well.)

[closebang] would be usually used for wholly different reasons. All the 
examples for [closebang] are unrelated to why pd needs [initbang]. The 
only reason why they're put together, is because they are two classes that 
are related to loadbang as all three send a bang at a specific special 

> It looks like the discussion just stopped, and I couldn't find any 
> threads on user or dev list.

What can you say more, on stuff that gets rejected without proper 
feedback, or ignored, for years ? At this point I would just say :




  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

More information about the Pd-list mailing list