[PD] Binary - integer conversion

[IOhannes m zmoelnig]

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