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

Jonathan Wilkes jancsika at yahoo.com
Tue Aug 24 22:17:16 CEST 2010


--- On Tue, 8/24/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: Tuesday, August 24, 2010, 8:57 AM
> On 2010-08-23 19:10, Jonathan Wilkes
> wrote:
> 
> > 
> > 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?
> 
> 
> right.
> on creation of the bus-sender, i dynamically create a proxy
> bus-receiver
> abstraction that receives the signal, does a fade in,
> delays the signal
> by a certain amount and adds it to the real summing bus.
> once the bus-sender get's destroyed it notifies the proxy
> receiver that
> the signal is going to vanish, and the proxy does a fade
> out (it has
> some time left, as it has delayed the signal) and then
> destroys itself.

I'd love to see an example of this in action.  Just from your 
description I'm wondering why you wouldn't do the fade from inside 
the abstraction, and just delay destroying it until the fade out has 
finished.

> 
> > Right-- in that case you would use Frank's
> method.  Although 
> > in an oscillator bank patch I made, sending a
> "loadbang" message 
> 
> this really depends on the original problem.
> in many cases it is enough to just re-trigger the loadbang
> (with the
> "loadbang" message).
> in other cases it is not enough.
> e.g. when you don't create all instances of your oscillator
> bank in zero
> logical time, but as they are needed.
> then you often don't want loadbangS to re-fire.
> this of course can easily be fixed by creating a
> [loadbangonce] abstraction.
> 
> but just because you can already solve some issues with the
> current
> mechanisms, doesn't mean that they can't be improved (esp.
> when the
> improvement makes things possible that are currently
> impossible)
> 
> > crashed Pd.  I changed it to [r $1-loadbang] as a
> workaround, but 
> > I never went back and hunted down the original
> problem.
> 
> which is a pity, as now there is only the rumour of a bug,
> which is way
> worse than a real bug (fixing a rumour proves harder than
> fixing a bug)

A rumor of a bug would be, "I heard this guy found a bug with 
loadbang, so don't use loadbang."  A _possibility_ of a bug would be, 
"Someone says they crashed Pd when sending a loadbang message in a 
dynamic patching context, though they couldn't verify whether this was 
a problem specifically with [loadbang]."  The _likelyhood_ of a bug 
can start to be gauged by whether people who hear the latter statement 
experience a crash under similar circumstances (or not).

Rumors can only start when people don't choose their words carefully.

> 
> >> 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]
> > 
> 
> as a matter of fact, i think [loadbang] has a bad naming as
> well.

But unless you have some extraordinarily clear name in 
mind as a replacement that outweighs the problems of replacing an object 
that is currently Max compatible and has a startup flag with its name in 
it (not to mention however many people's patches that depend upon it), 
there's not much to be done about it.

Hm, looking at Max's docs I see [loadbang] sends out a bang on double 
click.  That's pretty nifty!

-Jonathan

> 
> sdf
> 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