[PD] Concatenating two atoms into one?

IOhannes m zmoelnig zmoelnig at iem.at
Thu Oct 1 10:28:12 CEST 2020


On 2020-10-01 09:54, oliver wrote:
> IOhannes m zmoelnig wrote:
>> On 2020-10-01 09:22, hans w. koch wrote:
>>> but be aware of the risks of invoking makefilname all too often.
>>
>> note that if you use dollsyms (as in `[$1$2(`) you are filling up the
>> symbol table just as well.
> 
> i was just about to ask, if the attached modified patch would avoid that
> problem, but you replied already.
> 
> could you please clarify the used term "invoke" a bit ?
> i guess the number of [makefilename] objects isn't the problem, but how
> much/often its conversion mechanism is used, right ?

yes (the latter).

> 
> does that mean that everytime a number->symbol conversion happens
> (regardless how it is done) the symboltable is filled and will

no.
everytime a *new* symbol is created.
the point of symbols (vs ordinary strings) is, that a single literal
only needs to be stored once.
so if you first create a string "rubadub" (however you do this), a new
entry for the symbol 'rubadub' is created.
now, if you concatenate the symbols 'rubad' and 'ub', the result is
"rubadub", which already happens to be in the symbol table (and thus no
new entry needs to be generated).
for Pd these strings are *identical*.
this is cool as we can really easily compare the two strings. if they
occupy the same entry in the symbol table (which basically means, that
Pd gets the same pointer for when turning the literal into a symbol),
then the two strings are the same.
so rather than having to compare each character of the string
"sjfdjdasjfsfjrueincru057894_curtrfenr3ewf8354j3wp57jp3" with each
character of "sjfdjdasjfsfjrueincru057894_curtrfenr3ewfB354j3wp57jp3" ,
Pd only needs to compare two pointers - and this can be done in a single
step on your CPU.

the problem with generating symbol programmatically (e.g. by sending
numbers to [makefilename %d]) is, that it is so super easy to generate
lots and lots of (different) symbols.


> eventually slow down or crash PD ?
> 
> so, as a live example: writing number values to GUI labels dynamically
> is a potentially dangerous thing ? what's the threshold there ?

your computer memory will define the time when it will crash Pd (it will
crash, when all the strings in the symboltable eat up all the memory
available)

as for the slow-down, why not simply create a patch that tests this for you?

create labels with [makefilename label%08d] with the input ranging from
0...2000000 (or so; you'll notice when it gets slow).
measure the time it takes to generate the symbols (well, measure the
time it takes to generate 10000 symbols or)


> 
> or is there any way to clear the symboltable ?

i think i covered this in another ("the" other) post quite recently.


gfsdm
IOhannes




More information about the Pd-list mailing list