[PD-dev] initbang and friends WAS: run-up to release 0.43

Jonathan Wilkes jancsika at yahoo.com
Mon Aug 23 19:10:29 CEST 2010



--- On Mon, 8/23/10, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:

> From: IOhannes m zmoelnig <zmoelnig at iem.at>
> Subject: Re: [PD-dev] initbang and friends WAS: run-up to release 0.43
> To: pd-dev at iem.at
> Date: Monday, August 23, 2010, 6:07 PM
> On 2010-08-23 17:33, Hans-Christoph
> Steiner wrote:
> > 
> > Yeah, we definitely don't want [initbang] to be used
> too often, I can
> 
> i would also like to state, that we shouldn't use [metro]
> too often.
> reversely, one cannot use [trigger] too often.
> so Pd should print out a warning if there is no [t] in the
> patch
> whenever it is saved.
> 
> > understand that.  I just differ with how we
> should deal with the
> > problem.  I think it should be handled in the
> documentation rather than
> > making the programming part more complicated.
> 
> 
> seriously, i don't see so many drawbacks with [initbang].
> the biggest issue right now, is that there is no [initbang]
> in Pd-vanilla.
> this makes patches using [initbang] incompatible with
> Pd-vanilla.
> once it was included, this issue would become nought.

I agree that is the overriding issue.

> 
> > I could see the initbang help path having a section
> called "When to NOT
> > use initbang" then it would include your example below
> with the example
> > of how to use it.  
> 
> hmm, i guess some words are missing here, as i don't
> understand why we
> would include an example of how to use it in the "when to
> NOT use it"
> section.

I've revised the [initbang] help patch to include an example 
with dynamically creating an outlet.  But after reading about 
your use of [initbang] in realtime patching, I just need to 
change the wording a little to make it clear that it's not 
the _only_ use for [initbang]

Btw-- in your live-coding example you mentioned you were sending 
the audio to a bus and would use [initbang] to fade in.  But 
how do you use [closebang] to fade out?  Does [closebang] send 
a trigger to one of the sister abstractions to do the fade out?

> 
> 
> anyhow, in most cases [initbang] can be used as a
> replacement for
> [loadbang].
> the only difference is, that [initbang] will not make it to
> the outside
> of the patch using [outlet]s.

Right-- in that case you would use Frank's method.  Although 
in an oscillator bank patch I made, sending a "loadbang" message 
crashed Pd.  I changed it to [r $1-loadbang] as a workaround, but 
I never went back and hunted down the original problem.

> 
> 
> so you cannot use [initbang] to initialize the parent
> patch.
> darn, bad naming again.
> probably [createbang] would be better (esp. if [closebang]
> is renamed to
> [destroybang])
> or use [constructorbang] and [destructorbang]
> 
> 
> anyhow, whatever the name of the object (even [loadbang
> really-early]),
> th changes to the c-sources will be very similar.

[preloadbang]

> 
> 
> > The initbang help patch is in a pretty sorry state
> > right now...  its in SVN doc/pddp if anyone wants
> to take it on.
> 
> 
> probably we should wait whether this evolves before
> documenting things
> to be abandoned.

I'd rather risk irrelevant documentation in 2025 than have shoddy 
documentation right now.

-Jonathan

> 
> fgmasdr
> IOhannes
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
> 


      



More information about the Pd-dev mailing list