[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