IOhannes m zmoelnig wrote:
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).
The string in my example is the string of digits. Yes, I would personally just use a row of toggles. It simplifies inputting values, I can't imagine anyone starting with a decimal representation of a binary string to define a rhythm, what they want is the other way around.
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 did it to see if it would work, the name is irrelevant to me. I guess as far as string implies text, it was a bad idea. The object manages a list of bytes, so they are strings in the c sense except there is no trailing zero, and in the Pascal sense except that the length is kept beside the string, not in front. The strings may be stored and read from files but they aren't saved in the pd patch except as arguments to the str objects.
, 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).
As I said, if it's stored as an argument to a str object, 0 0 0 0 0 1 with spaces in between the digits involves no symbols, only floats. Even if that gets converted to 0.0 0.0 0.0 0.0 0.0 1.0 it won't affect the meaning. The str object doesn't use symbols internally except for the [str tosymbol] variant.
Martin