hi miller, hi devs ...
i wrote an abstraction using message-based patching ...
therefor, i was sending the messages to pd-test.pd ... but since it's an abstraction all other instances of test will receive the same message, resulting in the multiple creation of the object ...
to solve this, i had to use namecanvas $0-test... and send the messages there ... (example patch is attatched)
am i missing something obvious or is namecanvas not as obsolete as the helpfile says...
cheers ... tim
hi Tim,
perhaps, sending messages to [pd $0-localtest] subpatch inside of the [test] abstraction would be a bit cleaner?
Krzysztof
Tim Blechmann wrote: ...
therefor, i was sending the messages to pd-test.pd ... but since it's an abstraction all other instances of test will receive the same message, resulting in the multiple creation of the object ...
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
perhaps, sending messages to [pd $0-localtest] subpatch inside of the [test] abstraction would be a bit cleaner?
I guess, I'd second this. If I use abstractions in a patch, then I see these as being something rather static. They reside in the filesystem and a change of one abstraction should mean a change in all other instances, too. Subpatches however, especially those names with $0, are all through Pd used as areas to paint to, e.g. in graph structures. So they are meant to change their structure. And there are no abstractions named "$0-abs.pd".
But I admit, that's just my way of thinking in Pd.
Ciao
I guess, I'd second this. If I use abstractions in a patch, then I see these as being something rather static. They reside in the filesystem and a change of one abstraction should mean a change in all other instances, too. Subpatches however, especially those names with $0,
yes and no ... for most applications i'm using abstractions with $X arguments ... but sometimes i want to have abstractions with slightly different behaviour related to the arguments ...
cheers ... tim
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
I guess, I'd second this. If I use abstractions in a patch, then I see these as being something rather static. They reside in the filesystem and a change of one abstraction should mean a change in all other instances, too. Subpatches however, especially those names with $0,
yes and no ... for most applications i'm using abstractions with $X arguments ... but sometimes i want to have abstractions with slightly different behaviour related to the arguments ...
Yes, I can understand this, and I'd like Pd to be as flexible as possible, too. However I can only think of one occasion, where changing things inside a [pd $0-something] is not enough: Changing the number of inlets and outlets. Everything else is possible to do inside a named canvas created through subpatching, or isn't it?
Ciao
number of inlets and outlets. Everything else is possible to do inside a named canvas created through subpatching, or isn't it?
yes, but would add the overhead of one row of inlets and outlets ;-)
cheers ... t
Right, I'm rofgetting, the "pd $0-x" ends up naming the canvas "pd-$0-x" which is hard to generate as a symbol. My problem with "namecanvas" is that one can free or rename the patch (or just free the namecanvas object itself in the patch) and crash Pd. I still haven't found a clean alternative... so for now, I'll have to keep the mis-designed "namecanvas" object around for the forseeable future.
cheers Miller
On Wed, Dec 29, 2004 at 10:42:05PM +0100, Tim Blechmann wrote:
hi miller, hi devs ...
i wrote an abstraction using message-based patching ...
therefor, i was sending the messages to pd-test.pd ... but since it's an abstraction all other instances of test will receive the same message, resulting in the multiple creation of the object ...
to solve this, i had to use namecanvas $0-test... and send the messages there ... (example patch is attatched)
am i missing something obvious or is namecanvas not as obsolete as the helpfile says...
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
Right, I'm rofgetting, the "pd $0-x" ends up naming the canvas "pd-$0-x" which is hard to generate as a symbol.
True, but it's possible, however then we have the other problem: Sending to this target only works with either a set-able send or message sends like: [; $1 $2 $3 $4 ...( where $1 is created to be "pd-$0-x". The problem is: The argument count must be known in advance, which is not always possible in dynamic patching.
A solution could be $* in messages. Or, heresy!, let $0 work if it's not at the start of a symbol.
Ciao
Right, I'm rofgetting, the "pd $0-x" ends up naming the canvas "pd-$0-x" which is hard to generate as a symbol. My problem with "namecanvas" is that one can free or rename the patch (or just free the namecanvas object itself in the patch) and crash Pd. I still haven't found a clean alternative... so for now, I'll have to keep the mis-designed "namecanvas" object around for the forseeable future.
well ... what about a "thiscanvas" object (or a fancier name) that sends messages to the canvas it's created on ... this way, it's easy to access the canvas without renaming it ... that's much cleaner and could replace namecanvas ...
cheers ... tim
well ... what about a "thiscanvas" object (or a fancier name) that sends messages to the canvas it's created on ... this way, it's easy to access the canvas without renaming it ... that's much cleaner and could replace namecanvas ...
supposing ive made a region mapper like the one in Kontakt -idea apparently taken from upper-left img @ http://mediatheque.ircam.fr/articles/textes/Lindemann90/figure1.gif
,,which spits out commands to create an abstraction on the canvas with a particular $1 argument..is there any easy way to delete a particular one later on without keeping track of #s. like assigning an ID? or maybe "delete from thiscanvas where $1 == 'sector4-3'
hoping theres a way besides #s...but theres always a clever workaround waiting around the corner..
cheers ... tim
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
just like another c74's weapon, thispatcher... perhaps, does not need to be as overloaded with features...
k
Tim Blechmann wrote: ...
well ... what about a "thiscanvas" object (or a fancier name) that sends messages to the canvas it's created on ... this way, it's easy to access the canvas without renaming it ... that's much cleaner and could replace namecanvas ...
On Thu, 30 Dec 2004, Miller Puckette wrote:
Right, I'm rofgetting, the "pd $0-x" ends up naming the canvas "pd-$0-x" which is hard to generate as a symbol. My problem with "namecanvas" is that one can free or rename the patch (or just free the namecanvas object itself in the patch) and crash Pd. I still haven't found a clean alternative... so for now, I'll have to keep the mis-designed "namecanvas" object around for the forseeable future.
Hey, why not have _local_ variable-tables ? That would be a real cool feature, especially as it would eliminate symbol-table pollution by temporary names when instantiating the same abstraction many many times, especially dynamically. Each patcher would have some kind of variable-table which would be destroyed as the same time as the patcher, just like an object's state is destroyed at the same time as the object, and just like a C function's state is destroyed when that function returns.
The basic idea is to separate the registering of symbols (usually called "gensym" or "intern") from the setting/getting of values of variables. The reason why those two different things were conflated together was to save memory space, since those two tables typically had the same keys.
Historically, many systems have been implementing local variables in terms of a single global symbol-table, but for many reasons, few systems do it like that nowadays. The only remaining such examples I can think of are:
1. PureData 2. MAX 3. EmacsLisp
Most of the other Lisps and Lisp-inspired languages switched to having true local-variables during the 1970's. The only 1990's languages that were designed with an old-skool 1960's Lisp symbol-table are either:
1. Student homework in Compiler Theory courses (but only IF the prof doesn't forbid students from doing it)
2. That visual language called PureData.
Understood?
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
On Fri, 31 Dec 2004, Mathieu Bouchard wrote:
On Thu, 30 Dec 2004, Miller Puckette wrote:
Right, I'm rofgetting, the "pd $0-x" ends up naming the canvas
[...]
Most of the other Lisps and Lisp-inspired languages switched to having true local-variables during the 1970's. The only 1990's languages that were designed with an old-skool 1960's Lisp symbol-table are either:
- Student homework in Compiler Theory courses (but only IF the prof doesn't forbid students from doing it)
- That visual language called PureData.
Understood?
I wish not to say "other languages are doing things in this way, so why doesn't Pd just conform and submit to the inevitability of history?" ;-) but more like "other languages have already dealt with the issues that are nowadays cropping up in Pd, so why don't we consider how they have solved them when it happened to them?"
It's all a matter of identifying good solutions from other systems instead of reinventing the wheel in some other way. It's reuse at the design-level.
IMHO, this would be a good moment to consider such a solution for such a problem, and figure out a way to evolve Pd out of the problem while keeping some form of backward-compatibility with the current ($0) solution.
_____________________________________________________________________ Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
Historically, many systems have been implementing local variables in terms of a single global symbol-table, but for many reasons, few systems do it like that nowadays. The only remaining such examples I can think of are:
puh ... i just figured out, that my performance patch fills the symbol table with more than 10000 unique (!!!) symbols ... plus one additional symbol every second due my badly designed clock...
i'd strongly suggest to enlarge the hash-table any try to find a better solution for symbols ...
also ... after loading pd itself 397 symbol symbols are in use ... after including my .pdrc file 4400 are in use (more than twice the size of the hashtable) ... without loading any patch ...
cheers ... tim
i'd strongly suggest to enlarge the hash-table any try to find a better solution for symbols ...
something like: --- m_class.c.~1.3.4.4.~ 2004-11-24 19:25:03.000000000 +0100 +++ m_class.c 2005-01-02 14:13:33.086810696 +0100 @@ -501,7 +501,15 @@
/* ---------------- the symbol table ------------------------ */
+/* tb: new 16 bit hash table: multiplication hash */ +#define NEWHASH + +#ifndef NEWHASH #define HASHSIZE 1024 +#else +#define HASHSIZE 65536 +#define HASHFACTOR 40503 /* donald knuth: (sqrt(5) - 1)/2*pow(2,16) */ +#endif
/* tb: made dogensym() threadsafe */ t_symbol *dogensym(char *s, t_symbol *oldsym) @@ -512,7 +520,11 @@ #endif
t_symbol **sym1, *sym2; +#ifdef NEWHASH + unsigned short hash1 = 0, hash2 = 0; +#else unsigned int hash1 = 0, hash2 = 0; +#endif int length = 0; char *s2 = s; while (*s2) @@ -522,7 +534,12 @@ length++; s2++; } +#ifdef NEWHASH + hash2 = hash2 * HASHFACTOR; + sym1 = symhash + hash2; +#else sym1 = symhash + (hash2 & (HASHSIZE-1)); +#endif while (sym2 = *sym1) { if (!strcmp(sym2->s_name, s)) return(sym2);
after massively generating symbols in the (attached) patch, you can see that the new approach is much faster for systems with lots of symbols ...
drawbacks: big (very big) hash table 262kb for 16 bit hash
cheers ... tim
Hey, why not have _local_ variable-tables ? That would be a real cool feature, especially as it would eliminate symbol-table pollution by temporary names when instantiating the same abstraction many many times, especially dynamically. Each patcher would have some kind of variable-table which would be destroyed as the same time as the patcher, just like an object's state is destroyed at the same time as the object, and just like a C function's state is destroyed when that function returns.
Great idea!... i'll strongly support that!
best greetings, Thomas
-
Frank Barknecht -
ix -
Krzysztof Czaja -
Mathieu Bouchard -
Miller Puckette -
Thomas Grill -
Tim Blechmann