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