[PD] Binary - integer conversion

[Martin Peach]

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