--- 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
On 2010-08-24 22:17, Jonathan Wilkes wrote:
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.
ever tried to delay destroying an object? i'm mainly talking about objects that get automatically recreated by Pd (not where i just chose to remove the object because i don't like it any more)
Rumors can only start when people don't choose their words carefully.
you are very optimistic. at least i would rephrase to: "Rumors start because people cannot choose their words carefully."
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
i'm not suggesting to replace the name [loadbang].
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!
i think it's pretty daft, as a [loadbang] is a way to automate things without user interaction whereas double clicking only makes sense in user interaction. anyhow, if you think it's really missing roll your own (or use the attached)
fgmadr IOhannes
--- On Wed, 8/25/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: Wednesday, August 25, 2010, 9:13 AM On 2010-08-24 22:17, Jonathan Wilkes wrote:
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.
ever tried to delay destroying an object?
With mouse and cut messages, yes. With your objects, no. What happens?
i'm mainly talking about objects that get automatically recreated by Pd (not where i just chose to remove the object because i don't like it any more)
Rumors can only start when people don't choose their
words carefully.
you are very optimistic. at least i would rephrase to: "Rumors start because people cannot choose their words carefully."
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
i'm not suggesting to replace the name [loadbang].
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!
i think it's pretty daft, as a [loadbang] is a way to automate things without user interaction whereas double clicking only makes sense in user interaction.
Both Max and Pd's [loadbang] objects are a way to automate things without user interaction-- at _load_ time. Unless there is currently a way to imagine a patch into existence, one has to build a patch through interaction with Pd (or build the patch that dynamically builds a patch). In the course of doing so one probably wants to test that particular object chain. In Pd, you add an extra [bng] and connect it to whatever the [loadbang] connects to (or use the File->Message window but that takes longer and triggers any other [loadbang] in the patch). In Max, you add nothing-- you just double-click [loadbang]. It takes less time to add nothing than it does to add something, so in Max you save time when testing your [loadbang] patch.
I know it's a small amount of effort saved, but small amounts of effort start to add up over time, like [t b 0], having anchors to resize GUI objects with the mouse (like [entry]), etc.
anyhow, if you think it's really missing roll your own (or use the attached)
It's certainly missing, in the sense of, "If it were there, I would certainly use it." But given the difficulty of just advocating for [initbang], which has been around for years and (I find) necessary, I'm not sure I want to push for or code an addition to [loadbang] that merely adds a convenience.
Also, if you roll too many of your own in Pd, you end up doing so at the expense of portability. I don't want to send a library of my hacks to standard objects with every patch I show to someone else.
-Jonathan
fgmadr IOhannes
-----Inline Attachment Follows-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 2010-08-25 19:16, Jonathan Wilkes wrote:
Also, if you roll too many of your own in Pd, you end up doing so at the expense of portability. I don't want to send a library of my hacks to standard objects with every patch I show to someone else.
the implementation i attached in my last email was pd-vanilla.
it's a simple drop-in replacement abstraction for [loadbang] which does approximately what you asked for (i used single click rather than double click).
i don't consider "abstractions" to be "hacks" (at least as long as you give any of the usual negative connotations to the word).
mfasdr IOhannes
--- On Thu, 8/26/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at Subject: Re: [PD-dev] initbang and friends To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-dev@iem.at Date: Thursday, August 26, 2010, 9:05 AM On 2010-08-25 19:16, Jonathan Wilkes wrote:
Also, if you roll too many of your own in Pd, you end
up doing so at the
expense of portability. I don't want to send a
library of my hacks to
standard objects with every patch I show to someone
else.
the implementation i attached in my last email was pd-vanilla.
it's a simple drop-in replacement abstraction for [loadbang] which does approximately what you asked for (i used single click rather than double click).
I thought it wasn't possible to override internal objects with abstractions. (I'm guessing I'm right since you named your object "myloadbang" and not "loadbang".)
So why are you calling your example a "drop-in replacement"?
i don't consider "abstractions" to be "hacks" (at least as long as you give any of the usual negative connotations to the word).
It's a hack in the negative sense because I'm forced to care about whether I remembered to send the abstraction along with any patch where I use [myloadbang]. Or I have to remember to _not_ use myloadbang in simple patches, or remember to search and replace before I send it, or to zip it up with the patch. I'd rather have a hack in the positive sense, where I can really drop in my [loadbang] abstraction, make it override the internal, use the small convenience that I think it adds, then just send my vanilla patch to others (who, if they're just going to run my patch, aren't going to see the patching convenience of the abstraction anyway).
I think there are other situations where the user would like to try out a tweak to an internal object. For example, I might use a Max compatible [t] object and just continue to use it the way it is in Pd, but when my friends who use Max send me one of their patches their [t f 0] objects will work correctly.
-Jonathan
mfasdr IOhannes
On 2010-08-25 19:16, Jonathan Wilkes wrote:
ever tried to delay destroying an object?
With mouse and cut messages, yes. With your objects, no. What happens?
you are talking about a completely different thing than i am.
so let's reset this discussion to my original example.
it's probably easiest to show the problem in a little example (at the expense of being overly pedagagic)
please do the following: #1 create an abstraction "myabs.pd" #2 fill the abstraction with [f] #3 save the abstraction #4 open a new patch #5 add several instances of [myabs] to the patch #6 now open up one of the abstraction instances #7 add another object, e.g. [print]. #8 open up another instance of [myabs], and see, that it still only contains the [f]. #9 close the other instance #10 save the modified instance #11 open up another instance of [myabs], and you will see, that it has updated it's content to match the modified version
this is what you see. what is actually going on, is that whenever you save an abstraction instance, all other instances of the same abstraction will be deleted and re-created.
now please show me how you delay the deletion of all the sister abstractions, preferrably with "mouse" and "cut" messages.
apart from that, did you ever try to delete an object with "mouse" and "cut" in a closed window?
fgmasdr IOhannes