[PD] Binary - integer conversion

[Martin Peach]

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_support.patch
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
>
>