[PD] symbol anxiety

[Phil Stone]

Mathieu Bouchard wrote:
> On Mon, 23 Feb 2009, Roman Haefeli wrote:
>> for instance, when using OSC, probably every message is a new symbol. 
>> so i guess, it cannot be avoided, even if text processing is done 
>> outside of pd, unless a string type is introduced (is that correct?).
>
> Every OSC target is a symbol, just like every receive-symbol is a 
> symbol; but furthermore, even hierarchical names like /foo/bar are 
> recorded as a single name that doesn't use "foo" and "bar", instead of 
> using a list. Similarly, abstraction instances are _the_ way to flood 
> the table, as all the local receive-symbols and other local symbols 
> get multiplied by the number of instances.
>
> I proposed several solutions to this. Having deallocatable symbols 
> only is useful if you deallocate abstractions and reallocate them... 
> usually has to do with dynamic patching. The other solution would be 
> to make the symbol-table only a table of symbols, and have a separate 
> receiver-table, which would get accessed by ($0,symbol) pairs so that 
> the $0 doesn't get pasted inside of the symbol so that no more symbols 
> need be generated. That would be quite a major overhaul, but it's 
> pretty much the only real solution.
>
> I don't think that there's anything else in OSC that could be wasting 
> symbols. However, if you have a system where you use 1000000 OSC-paths 
> to represent an array of 1000000 numbers, you may be looking for trouble.

Since OSC messages have some value concatenated to the end, aren't they 
all potentially unique and therefore consumers of new symbols?  E.g.,  
"/oscillator/frequency 440.0" and "/oscillator/frequency 449.365" 
require distinct symbols, don't they?  And to think I was worried about 
a little stopwatch!  :-)


Phil