hello folks,
it's been a couple of years since IOhannes submitted his patch for constructor/destructor routines.. as far as i know only pd-extended has picked up the patch. could miller please consider this for inclusion into his stable branch?
without the [initbang] / [closebang] objects, pd is crippled to a static application of the abstraction philosophy, making it impossible to dynamically create inlets/outlets based on an abstractions arguments. this is really a silly limitation that has already been solved and should be put into regular practice where ever possible.
while i understand that miller has been hesitant to include such functionality, i would prefer it to be an included but undocumented feature (much like the role that [namecanvas] presently takes) than not included at all.
anyhow, there's a chance this will fall on deaf ears, but i would just like to register my vote for permanent inclusion.
many thanks as always,
dmotd
I also hereby clamor for this as well, although conservatively. =o)
I have always wondered -- does [namecanvas] have any historical use besides dynamic patching? It is necessary for the kind of dynamic patching you have in mind, since it's the name of the instance of the abstraction which needs to be sent messages, not the name of the abstraction class's patch.
Also, is there currently a way to dynamically delete individual patch objects without using mouse and keyboard events (and without [clear(-ing the whole patch)?
Thanks,
Matt
On Thu, Jan 29, 2009 at 12:27 PM, dmotd dmotd@gmx.net wrote:
hello folks,
it's been a couple of years since IOhannes submitted his patch for constructor/destructor routines.. as far as i know only pd-extended has picked up the patch. could miller please consider this for inclusion into his stable branch?
without the [initbang] / [closebang] objects, pd is crippled to a static application of the abstraction philosophy, making it impossible to dynamically create inlets/outlets based on an abstractions arguments. this is really a silly limitation that has already been solved and should be put into regular practice where ever possible.
while i understand that miller has been hesitant to include such functionality, i would prefer it to be an included but undocumented feature (much like the role that [namecanvas] presently takes) than not included at all.
anyhow, there's a chance this will fall on deaf ears, but i would just like to register my vote for permanent inclusion.
many thanks as always,
dmotd
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Check out IOhannes' iemguts library, he is working on making it possible to do everything with abstractions, including properties panels.
.hc
On Jan 29, 2009, at 7:20 PM, Matt Barber wrote:
I also hereby clamor for this as well, although conservatively. =o)
I have always wondered -- does [namecanvas] have any historical use besides dynamic patching? It is necessary for the kind of dynamic patching you have in mind, since it's the name of the instance of the abstraction which needs to be sent messages, not the name of the abstraction class's patch.
Also, is there currently a way to dynamically delete individual patch objects without using mouse and keyboard events (and without [clear(-ing the whole patch)?
Thanks,
Matt
On Thu, Jan 29, 2009 at 12:27 PM, dmotd dmotd@gmx.net wrote:
hello folks,
it's been a couple of years since IOhannes submitted his patch for constructor/destructor routines.. as far as i know only pd-extended has picked up the patch. could miller please consider this for inclusion into his stable branch?
without the [initbang] / [closebang] objects, pd is crippled to a static application of the abstraction philosophy, making it impossible to dynamically create inlets/outlets based on an abstractions arguments. this is really a silly limitation that has already been solved and should be put into regular practice where ever possible.
while i understand that miller has been hesitant to include such functionality, i would prefer it to be an included but undocumented feature (much like the role that [namecanvas] presently takes) than not included at all.
anyhow, there's a chance this will fall on deaf ears, but i would just like to register my vote for permanent inclusion.
many thanks as always,
dmotd
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
yes, iemguts is a very exciting for abstraction development and i also hope that these functions will eventually flow into the core package. these methods accompanied with data structures and graph on parent make for some very interesting and sophisticated interfacing methods for abstractions, it certainly adds another dimension to the pd gui..
cheers, dmotd
On Friday 30 January 2009 12:26:40 Hans-Christoph Steiner wrote:
Check out IOhannes' iemguts library, he is working on making it possible to do everything with abstractions, including properties panels.
.hc
On Fri, 30 Jan 2009, dmotd wrote:
hello folks, [...] could miller please consider this for inclusion into his stable branch?
So, is this a letter made for pd-dev or made for Miller ? In the latter case, wouldn't it be better to just write a personal letter ? In any case, what can anybody else do about it that already hasn't been done?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
yes quite right, miller is probably my target audience for this request, although i don't really see anything wrong with posting here, any discussion generated may be worth while and pd is notorious for interesting work- arounds.. or i may simply be put in my place..
On Saturday 31 January 2009 05:59:18 Mathieu Bouchard wrote:
So, is this a letter made for pd-dev or made for Miller ? In the latter case, wouldn't it be better to just write a personal letter ? In any case, what can anybody else do about it that already hasn't been done?
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
On Sat, 31 Jan 2009, dmotd wrote:
yes quite right, miller is probably my target audience for this request, although i don't really see anything wrong with posting here, any discussion generated may be worth while and pd is notorious for interesting work- arounds.. or i may simply be put in my place..
The only worthwhile workaround is to stop relying on pure vanilla, that's all. Hack your vanilla or use pd-extended, whichever. That's the only interesting discussion I can think of.
Well, ok, you _can_ do something by modifying [canvas]'s savefn from an external's setup, but that's damn desperate.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
-
dmotd -
Hans-Christoph Steiner -
Mathieu Bouchard -
Matt Barber