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 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.
Sorry to confuse; I meant my patch to pd that implements strings in pd. Assuming you have a version of pd with string support and have the [str] external as well, if you write the string with spaces between the numbers, the string will consist of zeros and ones (as bytes). (without the spaces it would be interpreted as a sequence containing the characters 1 and 0, i.e. 49 and 48) The string won't be saved in the patch, but the arguments to the [str] object will, and since they are 0 and 1 they won't be clipped or misinterpreted even if there are a lot of them. This is not part of pd (yet). This is yet another application where it could be useful... See http://pure-data.cvs.sourceforge.net/pure-data/packages/patches/add_string_s... and http://pure-data.cvs.sourceforge.net/pure-data/externals/mrpeach/str/
of course you could also use some prefix to enforce it a symbol, like #100110100, but then you have an additional character just to workaround pd's limitations with string handling. using +--++-+- (or IOIIIOIOI, or ...) is cleaner in a sense that it totally represents the 101001 scheme but deals (as opposed to works around) pd's shortcomings.
That would work too. Is there a limit to the length of such a symbol?
Martin
mfga.sdr IOhannes