On Mon, 3 Sep 2007, Thomas O Fredericks wrote:

Then what should I call it? "freesend" or "destroysend" or "destructorsend"

i don't know, there isn't a standard word for that at the pd level... at the C level, Pd internals call it "free". however, those "free" callbacks don't free the structure itself, they're more like a C++ destructor. In C++, you call operator delete, which calls the destructor and then call the equivalent of free(). So in a sense, "destroysend" or "destructorsend" would be better.

"On top of this, it gets triggered in the middle of deleting a patch, which means you can't rely on the patch being complete and you can't rely on the patch being empty either. "

This is not an issue with this external as it is made to annonce to another patch that the current patch is being deleted.

You are doing what is perhaps the best thing that can be done without modifying pd itself, but I'd rather have [closebang], perhaps named differently.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

That is why this object's name will change. It will be called "destroysend" because it sends a "bang" when it is destroyed. It is designed for inter patch communication NOT inner patch communication.

After your receive object, simply add a delay message with 0 for time and you should be sure that the whole patch will be deleted by the time the bang makes it out the delay.

Tom

On 9/4/07, Roman Haefeli reduzierer@yahoo.de wrote:

On Mon, 2007-09-03 at 13:33 -0400, Mathieu Bouchard wrote:

...

[closemsg] gets triggered too late for that. On top of this, it gets triggered in the middle of deleting a patch, which means you can't rely on the patch

being

...

complete and you can't rely on the patch being empty either.

when does it exactly trigger? is it true, that it depends on creation time? i made some tests with the help-patch: if [closemsg xx] is created _before_ [r xx]-[print], then the message gets printed, when closing the patch. on the other hand, if [closemsg xx] is created _after_ [r xx]-[print], no message gets printed, when closing the patch. i'd say, the most desirable behaviour would be, that it 'bang's before anything is destroyed. this behaviour would ensure, that everything within the patch itself, that is triggered by [closemsg], would be executed. as it is now, it is not clearly defined, whether messages get executed or not.

roman

---

Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

I have been waiting (count in years) for the long promised closebang. As for many PD promises, I am tired of waiting... I got work to do!

I will not patch my PD (or use a special version) because I want my patches to be cross-platform and accessible to all users.

"am i correct that your external will be void if [closebang] ever makes it into pd?" Yes, if it ever does make it (probably at the same time as the threaded soundfiler). But that is not an issue. iem_send is voided by PD 0.4, but I still use it, because a lot of people use PD 0.39 extended and I want to share with them.

"As you describe the behaviour of your object IMHO it sounds not very consistent and would possibly introduce bugs in patches ..."

If used properly (as for inter-patch and not inner-patch stuff) it should not. No using [t a a ] to connect multiple multiple inlets to one outlet will possibly introduce bugs also.

Thomas O Fredericks wrote:

That is why this object's name will change. It will be called "destroysend" because it sends a "bang" when it is destroyed. It is designed for inter patch communication NOT inner patch communication.

just because i am curious: how does your object relate to the [closebang] object (apart from the fact, that [closebang] is meant to be an internal and not yet accepted by miller (yet)). am i correct that your external will be void if [closebang] ever makes it into pd?

mfda.r IOhannes