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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list