Martin Peach wrote:
IOhannes m zmoelnig wrote:
Martin Peach wrote:
Also if my string patch is applied to pd, you can use [str drip 1 0 1 0 1 0 0 0 1 0 1 1] to output that sequence one at a time. Since the floats
then why the hell do you need [str drip]? there is no stringish content in your example, so you could as well use pure pd objects (see frank's list abstractions), or zexy's [drip] & [repack] (which are as well externals as your [str] but don't require pd to be patched).
are always 1 or 0 there won't be any problems with long strings.
in theory this is correct. nevertheless, when saving a patch containing a "string" (this is: a symbol) "101", pd will eventually parse this as number 101.0 on re-loading the patch. therefore i proposed a truly symbolic representation.
no, i don't think so.
even though i haven't looked closely at your "string"-implementation (which really should be called "blob" rather than "string", imho), i doubt whether it interferes at all with pd's saving mechanism which is the problem here (at least: which is the problem i am talking about).
the internal symbol representation is an as "truly symbolic representation" as your strings are there are other problems with symbols, like the infinetely growing hash-table; this is (to my knowledge) somewhat addressed by your strings; but this has nothing to do with the problem of storing the token "000001" in pd: at the best it will be stored as "000001", but on loading the patch it will be become "1" (which might be appropriate, but might as well not).
That would work too. Is there a limit to the length of such a symbol?
no there is not. (but there is a limit to what pd will display via [print] or in message/symbol-boxes. but the symbols can be any lengths)
mfg.asdr IOhannes