[PD] symbol anxiety

[Phil Stone]

Phil Stone wrote:
> 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!  :-)
>
>   
On further reflection, the OSC path (which *is* a symbol) and the value 
(which *may* be a symbol, but is more typically a float) are two list 
items, so the answer to my question is no, I think.


Phil