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