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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
