--- On Mon, 8/23/10, IOhannes m zmoelnig <zmoel...@iem.at> wrote:
> From: IOhannes m zmoelnig <zmoel...@iem.at> > Subject: Re: [PD-dev] initbang and friends WAS: run-up to release 0.43 > To: pd-dev@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@iem.at > http://lists.puredata.info/listinfo/pd-dev > _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev