hi.
i just submitted a patch against the 0.40-prerelease that adds a new object [initbang], which can be used to trigger a constructor in an abstraction.
this allows to have abstractions with runtime customizable constructors, especially variable inlets/outlets. ([loadbang] is a bit too late for such things, as it only gets called when the parent of an abstraction is already finished (and connections have been abandoned))
i think this is another important step on making abstractions objects of full age.
any thoughts?
what is still missing is the possibility for an abstraction to do something before it is destroyed.
mfg.asdr IOhannes
On Mon Aug 21, 2006 at 06:07:38PM +0200, IOhannes m zmoelnig wrote:
hi.
i just submitted a patch against the 0.40-prerelease that adds a new object [initbang], which can be used to trigger a constructor in an abstraction.
this allows to have abstractions with runtime customizable constructors, especially variable inlets/outlets. ([loadbang] is a bit too late for such things, as it only gets called when the parent of an abstraction is already finished (and connections have been abandoned))
i think this is another important step on making abstractions objects of full age.
any thoughts?
sounds useful. it recently came up on IRC that abstraction-loadbangs don't work properly:
21:44 ClaudiusM internal messaging question: why don't abstractions you create with "; pd-blah obj 1 2 myabstraction a b c" get loadbang'd? 21:55 ClaudiusM hmm, i think i can create a receive in the abstraction dependant on abstraction arguments and send a bang to that... 22:02 ClaudiusM can i do this in each abstraction i want to really loadbang on dynamic creation? [r MEGA_HACKY_LOADBANG_MEGA_HACK]--[once]--[f $0]--[makefilename pd-%d-myabstraction.pd]--"; $1 loadbang"
one step closer to having full python/c++ style OO :D
Hallo, carmen hat gesagt: // carmen wrote:
sounds useful. it recently came up on IRC that abstraction-loadbangs don't work properly:
21:44 ClaudiusM internal messaging question: why don't abstractions you create with "; pd-blah obj 1 2 myabstraction a b c" get loadbang'd? 21:55 ClaudiusM hmm, i think i can create a receive in the abstraction dependant on abstraction arguments and send a bang to that... 22:02 ClaudiusM can i do this in each abstraction i want to really loadbang on dynamic creation? [r MEGA_HACKY_LOADBANG_MEGA_HACK]--[once]--[f $0]--[makefilename pd-%d-myabstraction.pd]--"; $1 loadbang"
This problem already has another fix, which isn't as known as it should be.
Instead of [r MEGA_HACKY_LOADBANG_MEGA_HACK] you should just send the message "loadbang" to the subpatch's receiver:
[; pd-subpatch obj 10 20 myabstraction; pd-subpatch loadbang(
See attached.
Why auto-generated abstractions don't receive a loadbang autoamtically has been discussed several times in the past. I don't remember the reasons, but there were reasons.
Ciao
On Mon, 21 Aug 2006, Frank Barknecht wrote:
you should just send the message "loadbang" to the subpatch's receiver: [; pd-subpatch obj 10 20 myabstraction; pd-subpatch loadbang(
Yes, that's how it should be done.
Why auto-generated abstractions don't receive a loadbang autoamtically has been discussed several times in the past. I don't remember the reasons, but there were reasons.
So that objects may send messages to other objects through the wires, when the patch gets loaded. If it were done exactly at the time of object creation, then it would be too early, as the object wouldn't have been connected yet.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
i just submitted a patch against the 0.40-prerelease that adds a new object [initbang], which can be used to trigger a constructor in an abstraction.
this allows to have abstractions with runtime customizable constructors, especially variable inlets/outlets.
I like this. ;)
what is still missing is the possibility for an abstraction to do something before it is destroyed.
This would be even better. For example in [sssad] I'm using the singleton.pd we once made together. This implements the singleton pattern in a naive way by just incrementing a [value] and dynamically creating its first argument as an object, if the counter still is zero.
Now if you use several of these and then delete the one that was created first, you are in fact deleting your single instance of the singleton-managed object and all hell breaks loose. Kind of. For fixing this, a closebang would be the first thing that is needed.
Ciao
Frank Barknecht wrote:
what is still missing is the possibility for an abstraction to do something before it is destroyed.
This would be even better. For example in [sssad] I'm using the
i am not sure if it is "even better", though it certainly has its uses.
Now if you use several of these and then delete the one that was created first, you are in fact deleting your single instance of the singleton-managed object and all hell breaks loose. Kind of. For fixing this, a closebang would be the first thing that is needed.
actually this example belongs to the only group of objects where i can see the use for a closebang. the other important family would be freeing ressources (memory, ports,...) which currently can only be reserved via external code and thus can also be released via external code (where we already have destructors)
mfg.dr IOhannes
On Mon, 21 Aug 2006, IOhannes m zmoelnig wrote:
actually this example belongs to the only group of objects where i can see the use for a closebang.
It shouldn't be called "closebang" because in the case of abstractions the thing called "close" only closes the window, so it only hides the instance, not destroying it. If it destroyed the instance, it could be called:
* "delete" in C++ calls the destructor and frees the memory * destructor in C++ never frees memory * "delete" in DesireData GUI is both a destructor and frees the memory * "free" in PureData C interface is both a destructor and frees the memory * "free" in C just frees the memory * "free" in Ruby C interface is both a destructor and frees most of the memory * "finalize" in Ruby and Java is a destructor but never frees memory
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Mon, 21 Aug 2006, IOhannes m zmoelnig wrote:
actually this example belongs to the only group of objects where i can see the use for a closebang.
It shouldn't be called "closebang" because in the case of abstractions the thing called "close" only closes the window, so it only hides the instance, not destroying it. If it destroyed the instance, it could be called:
- "delete" in C++ calls the destructor and frees the memory
- destructor in C++ never frees memory
- "delete" in DesireData GUI is both a destructor and frees the memory
- "free" in PureData C interface is both a destructor and frees the
memory
- "free" in C just frees the memory
- "free" in Ruby C interface is both a destructor and frees most of the
memory
- "finalize" in Ruby and Java is a destructor but never frees memory
right, the names could be subject to discussion: [initbang] is really a bad name, as it makes you think of initialization rather than creation. i liked [closebang] because of ... probably the sound.
closebang:: i think [freebang] might be a nice name. from a technical side, [deletebang] might be better.
initbang:: probably [createbang] as it bangs after creation. or [newbang] (esp. if the destructor-bang is called [deletebang])
changing the patch to better names is left as an exercise for the user.
mfg.asdr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
right, the names could be subject to discussion: [initbang] is really a bad name, as it makes you think of initialization rather than creation. i liked [closebang] because of ... probably the sound.
closebang:: i think [freebang] might be a nice name. from a technical side, [deletebang] might be better.
[unloadbang]
Ciao
hi
Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
what is still missing is the possibility for an abstraction to do something before it is destroyed.
This would be even better. For example in [sssad] I'm using the
[...]
Now if you use several of these and then delete the one that was created first, you are in fact deleting your single instance of the singleton-managed object and all hell breaks loose. Kind of. For fixing this, a closebang would be the first thing that is needed.
seems to be xmas: http://sourceforge.net/tracker/index.php?func=detail&aid=1544041&gro...
mfg.ad.sr IOhannes
Hi Iohannes, hi Thomas, i just realized that the message objects of the iem_t3_lib don't react upon samplerate or blocksize changes although they should. Attached is a patch that should fix that.
greetings, Thomas
once again, here's the right one.....
Thomas Grill schrieb:
Hi Iohannes, hi Thomas, i just realized that the message objects of the iem_t3_lib don't react upon samplerate or blocksize changes although they should. Attached is a patch that should fix that.
greetings, Thomas
hi
Thomas Grill wrote:
once again, here's the right one.....
Thomas Grill schrieb:
Hi Iohannes, hi Thomas, i just realized that the message objects of the iem_t3_lib don't react upon samplerate or blocksize changes although they should. Attached is a patch that should fix that.
hmm
+static void t3_metro_dsp(t_t3_metro *x, t_signal **sp) +{
- x->x_ticks2ms = 1000.0*(double)sys_getblksize()/(double)sys_getsr();
+}
this does not react on blocksize changes either, and the samplerate changes it reacts on are only changes to the playback (soundcard!) samplerate (e.g. when you change the samplerate via the menu (or pd-messages) which is not the thing you usually do)
the blocking of the canvas will be completely ignored by this patch. however, in your first patch (the "wrong" one) you also took [block~] into account. what is the reason to discard this solution?
mfg,asdr IOhannes
PS: i think that all (and more) of the functionality of iem_t3_lib can be done with the builtin [vline~] object.
Hi,
this does not react on blocksize changes either, and the samplerate changes it reacts on are only changes to the playback (soundcard!) samplerate (e.g. when you change the samplerate via the menu (or pd- messages) which is not the thing you usually do)
the blocking of the canvas will be completely ignored by this patch. however, in your first patch (the "wrong" one) you also took [block~] into account. what is the reason to discard this solution?
i wasn't sure if the blocking really has an impact on the t3 messages, but you might be right. With the patch i only wanted to mirror driver-related changes. I had to discard the first solution, because the objects don't have signal inlets or outlets, so they won't get signal vectors to take sr and n from.
PS: i think that all (and more) of the functionality of iem_t3_lib can be done with the builtin [vline~] object.
probably, but one has to go to the signal domain then, taking much more cpu.
greetings, Thomas
-- Thomas Grill http://grrrr.org
Thomas Grill wrote:
Hi,
i wasn't sure if the blocking really has an impact on the t3 messages, but you might be right. With the patch i only wanted to mirror driver-related changes. I had to discard the first solution, because the objects don't have signal inlets or outlets, so they won't get signal vectors to take sr and n from.
well yes, but that is easy to fix.
PS: i think that all (and more) of the functionality of iem_t3_lib can be done with the builtin [vline~] object.
probably, but one has to go to the signal domain then, taking much more cpu.
?? you only get the sample accuracy of iem_t3 when you swap to signal domain (with [t3_sig~] and [t3_line~]); that's the whole point of the library: to let messages happen at a certain moment in the signal~ scheduler. this is, what [vline~] also provides. as long as you are using iem_t3_lib only(!) in message domain, you will gain exactly no precision. (in message domain we are dealing with idealized time anyhow)
mfga.sdr IOhannes
Am 23.08.2006 um 11:30 schrieb IOhannes m zmoelnig:
Thomas Grill wrote:
Hi, i wasn't sure if the blocking really has an impact on the t3 messages, but you might be right. With the patch i only wanted to mirror driver-related changes. I had to discard the first solution, because the objects don't have signal inlets or outlets, so they won't get signal vectors to take sr and n from.
well yes, but that is easy to fix.
sure, but it's your decision to give to objects a signal inlet, which i didn't want to take.
PS: i think that all (and more) of the functionality of iem_t3_lib can be done with the builtin [vline~] object.
probably, but one has to go to the signal domain then, taking much more cpu.
?? you only get the sample accuracy of iem_t3 when you swap to signal domain (with [t3_sig~] and [t3_line~]); that's the whole point of the library: to let messages happen at a certain moment in the signal~ scheduler. this is, what [vline~] also provides. as long as you are using iem_t3_lib only(!) in message domain, you will gain exactly no precision. (in message domain we are dealing with idealized time anyhow)
what you get is a kind of time-stamped metro which can have message- based applications too. I have to say that i won't use the t3-objects themselves, just looked into them - but i'll use some mechanics of them for some more general clocking functionality.
greetings, Thomas
-- Thomas Grill http://grrrr.org
Thomas Grill wrote:
well yes, but that is easy to fix.
sure, but it's your decision to give to objects a signal inlet, which i didn't want to take.
i see. btw, thanks for looking at the code (it seems like i haven't said anything positive about your bug-report+fix yet; this doesn't mean that we are not thankful)
what you get is a kind of time-stamped metro which can have message-based applications too. I have to say that i won't use the t3-objects themselves, just looked into them - but i'll use some mechanics of them for some more general clocking functionality.
ok but each message in pd is implicitly timestamped, so there is no use for such a feature, _unless_ you need explicit timestamps, which do not necessarily correspond to the exact time of the message. (e.g. scheduling messages in the future)
mfga.sdr IOhannes
ok but each message in pd is implicitly timestamped, so there is no use for such a feature, _unless_ you need explicit timestamps, which do not necessarily correspond to the exact time of the message. (e.g. scheduling messages in the future)
that's the point!
greetings, Thomas
-- Thomas Grill http://grrrr.org
On Mon, Aug 21, 2006 at 07:06:10PM +0200, Frank Barknecht wrote:
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
i just submitted a patch against the 0.40-prerelease that adds a new object [initbang], which can be used to trigger a constructor in an abstraction.
what is still missing is the possibility for an abstraction to do something before it is destroyed.
This would be even better. For example in [sssad] I'm using the
Also cool for [sssad] would be a [savebang] which could be used to cascade the save to save user (memento or sssad or whatever) data when the user saves the patch.
Sorry to make feature requests without submitting code.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
I just realized that this is going to be quite useful. I tried in the past to make a Pd object with a dynamic number of inlets, and started to make some crazy system where I would start out with 20 outlets, then delete all but the number that were needed.
I'll try it with [initbang] now.
FYI: I added the patch to Pd-extended, so you can try it out on upcoming auto-builds.
.hc
On Aug 21, 2006, at 12:07 PM, IOhannes m zmoelnig wrote:
hi.
i just submitted a patch against the 0.40-prerelease that adds a new object [initbang], which can be used to trigger a constructor in an abstraction.
this allows to have abstractions with runtime customizable constructors, especially variable inlets/outlets. ([loadbang] is a bit too late for such things, as it only gets called when the parent of an abstraction is already finished (and connections have been abandoned))
i think this is another important step on making abstractions objects of full age.
any thoughts?
what is still missing is the possibility for an abstraction to do something before it is destroyed.
mfg.asdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
-
carmen -
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Thomas Grill