On Mon, Feb 13, 2006 at 01:17:38PM +0100, Frank Barknecht wrote :

Hallo, Item State hat gesagt: // Item State wrote:

...

is there any means to get segmented patch chords in PD?

Maybe in DesireData? But not in main Pd.

erm, yes, segmented patch chords is on the list of things that will be in DesireData. however, the development of DD has been a little slow since the end of last year (but hopefully will pick up again soon). so it will sometime till its useable...

cheers

chun

...

as soon as i have a few feedback / recursive structures, the patch is terribly unreadable IMO.

Just guessing, but maybe you should use more abstractions?

...

otherwise, are there some truly local send/receive objects, that is not those fake mechanism using a patcher instance number in the port name, something like PVar or PV in max?

What's so fake about $0? There are some externals like [sl] in GGEE, if you don't like to see the $0. I don't know what PV(ar) is.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

"Frank Barknecht" fbar@footils.org wrote:

I once proved, that segmented patch cords don't solve all problems anyway. The proof is attached again as a reminder.

hihi...yes, i remember well ('you wanna segmented patch cords, huh? i gives you segmented patch chords....' :-)

hi mathieu

"Mathieu Bouchard" matju@artengine.ca wrote:

...

$0-send/receive: what would be the difference to a NOT-fake-mechanism?

Avoiding pollution of the symbol-table?

this topic has been mentioned already a few times on this list, but suddenly i still don't know what this means exactly. does pollution mean, that the symbol-table uses a lot of ram? does that have any bad effects on performance? is there a good way to avoid pollution (i mean when patching) ?

roman

___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

thnx to matju and item for your answers

it's very good to know all this info. in fact i already made installations, where a pd-patch is running during the whole day (although i believe it is not an issue in this specific case).

i'm still not quite sure if i undesrstand it correctly. are only symbols like array-names, [send]s and [receive]s, [throw~] and [catch~] etc stored in pd's symbol-table (which i assume)? or does also sending a lot of messages and using [route symbol] lead to a pollution of the symbol-table?

if the first case is true, there are maybe some ways to avoid too much pollution. in case of netpd for example it happens that often a bunch of patches are open and each of them uses a lot of send/receive-symbols. now, if i understand it right, using:

[r mysynth] | [route freq amplitude]

causes less pollution than something like this:

[r mysynth-freq]

[r mysynth-amplitude]

is that right? is it also better to use short symbols or doesn't that matter?

roman

On Tue, 14 Feb 2006 07:32:58 -0500 (EST) Mathieu Bouchard matju@artengine.ca wrote:

On Tue, 14 Feb 2006, Roman Haefeli wrote:

...

"Mathieu Bouchard" matju@artengine.ca wrote:

...

...

$0-send/receive: what would be the difference to a NOT-fake-mechanism?

Avoiding pollution of the symbol-table?

this topic has been mentioned already a few times on this list, but suddenly i still don't know what this means exactly. does pollution mean, that the symbol-table uses a lot of ram? does that have any bad effects on performance? is there a good way to avoid pollution (i mean when patching) ?

Pd starts up with a fixed-size symbol-table. This is a big array of symbols. If the table becomes full (or even just crowded) there are more and more symbols that share the same cell in the symbol-table by chaining one symbol to another. Long chains of symbols are slow. If you use many symbols, the quick fix is to increase the size of the table but to do that you need to recompile pd.

Most of the problem of having many symbols comes from the fact that most symbols have two parts, because they're made like $0-foo where $0 is some integer. There's no quick escape from that. Pd needs a new atom type for local symbols. When it gets it, all externals would have to be updated in order to support it.

The other main cause of symbol pollution is that pd doesn't have text strings. Strings can be deallocated, while symbols are æternal, that is, until you quit pd. If you use pd for heavy string processing in an art installation, make sure you do scheduled shutdowns in order to prevent swapping, thrashing and crashing; make tests and extrapolations to figure out when it would have used all of your RAM, etc.

_ _ __ ___ _____ ________ _____________ _____________________ ... | 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:

Roman Haefeli wrote:

...

[r mysynth] | [route freq amplitude]

this uses at least 5 symbols ("r", "mysynth", "route", "freq", "amplitude")

Though "r" and "route" probably are already used anyway, so these two shouldn't matter (or do they?).

...

causes less pollution than something like this:

[r mysynth-freq]

[r mysynth-amplitude]

this uses at least 3 symbols ("r", "mysynth-freq", "mysynth-amplitude")

Still I often prefer the first idiom, simply because in my patches, "receiver namespace pollution" is more a problem than the size of the symbol table. Many things in Pd can become targets for senders, most notably these are tables, subpatches and real receivers.

Limiting the chances of accidentally hitting one of these is quite important to me. That's why I almost always use $0 to name tables, receivers and even subpatches, and I tend to use UPPERCASE names for everything, which doesn't have $0 in front, to make it even more clear, that these are not only accessible, but generally also intended for global access.

Somehow related to this:

I'm still undecided if [struct] names should also be named with $0. It's easier to work with when embedding [struct]s in abstractions and to avoid possible name clashes. However it's much harder to save and restore the contents of a graph subpatch to a file, if the name contains $0. This still is an open question when I really start to build RRADical abstractions that use data structure GUIs: Should I embed or should I require users to open a graph library patch? And how do I make sure, that this graph library patch will be open exactly once? Any ideas for how to implement such a Singleton pattern in Pd?

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

hi frank

if you want to load something just once (like [table a] or maybe a 'graph library patch'). I used that once when dynamically created table in different abstractions without knowing whether the table already existed or not.

maybe there is a simpler method.

cheers eni

On Feb 15, 2006, at 12:06 AM, Frank Barknecht wrote:

And how do I make sure, that this graph library patch will be open exactly once? Any ideas for how to implement such a Singleton pattern in Pd?

Enrique Erne wrote:

hi frank

if you want to load something just once (like [table a] or maybe a 'graph library patch'). I used that once when dynamically created table in different abstractions without knowing whether the table already existed or not.

maybe there is a simpler method.

i would recommend using [value] to hold the something like the "instance counter".

attached is your example modified accordingly (i also did some cleanups, esp. emptying the $0-container)

mfg.asdr IOhannes

#N canvas 440 52 627 636 10; #N canvas 0 22 236 173 1004-container 0; #X restore 227 18 pd $0-container; #X obj 114 300 f $0; #X obj 114 320 makefilename pd-%d-container; #X obj 47 18 loadbang; #X obj 47 491 outlet; #X obj 77 418 pack s s; #X obj 47 82 value $1.st.req; #X obj 47 261 select 0; #X obj 47 107 t f f; #X obj 77 127 + 1; #X obj 77 147 value $1.st.req; #X obj 47 285 t b b; #X msg 47 469 1; #X obj 114 341 t s s; #X msg 144 363 ; $1 clear; #X obj 77 397 symbol $1; #X msg 77 446 ; $2 obj 10 10 table $1; #X text 189 90 more simple-minded , we would just set $1.st.req to "1" instead of incrementing it each time. (however , this way we also now how many instances of the class we have). and of course we could use just one [value] - i use 2 for better readability.; #X obj 346 320 del 0; #X obj 47 48 t b b b; #X obj 346 339 value $1.st.req; #X floatatom 346 362 5 0 0 0 - - -; #X text 386 365 wow! the number of instances; #X connect 1 0 2 0; #X connect 2 0 13 0; #X connect 3 0 19 0; #X connect 5 0 16 0; #X connect 6 0 8 0; #X connect 7 0 11 0; #X connect 8 0 7 0; #X connect 8 1 9 0; #X connect 9 0 10 0; #X connect 11 0 12 0; #X connect 11 1 15 0; #X connect 12 0 4 0; #X connect 13 0 5 1; #X connect 13 1 14 0; #X connect 15 0 5 0; #X connect 18 0 20 0; #X connect 19 0 6 0; #X connect 19 1 1 0; #X connect 19 2 18 0; #X connect 20 0 21 0;

Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:

...

i would recommend using [value] to hold the something like the "instance counter".

Yep, a value is even better. Removing the "table" inside the message and maybe allowing more arguments instead (e.g. with [list append $1 $2 $3 ...]) this could be made to a very useful abstraction. I propose to use the name "singleton" then.

thanks iohannes for enhancement!

indeed singleton.pd would be useful sometimes.

cheers

Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:

Attached is a version with slightly different behaviour. It is intended to be able to create any object including up to 10 arguments. Additionally I chose to use a special singleton "tag" as first argument to support creating "twingletons". You'll see in the help-patch what I mean.

Forgot to say: This *strictly* requires a pd >= 0.39. 0.38 even with backported [list] will not work, because I used the new message-methods "adddollar" etc. to fake [dollarg] from IEMlib.

Ciao

Frank Barknecht _ ______footils.org_ __goto10.org__

Frank Barknecht hat gesagt: // Frank Barknecht wrote:

...

Attached is a version with slightly different behaviour.

And now it became even simpler.

terrific! thanks frank

usually this is not a real problem, if you are not working with long texts and if you are not constantly generating a lot of symbols (e.g. connect a counter to [makefilename bla-%d])

I date and time stamp files recorded in installations which run for a long time (years). What are some of the problems I would potentially encounter after generating thousands of filenames with this method?

cgc