File: README.txt

package info (click to toggle)
pd-pdstring 0.10.2-4
  • links: PTS, VCS
  • area: main
  • in suites: bookworm, bullseye, buster, sid
  • size: 640 kB
  • sloc: ansic: 860; sh: 787; makefile: 75
file content (49 lines) | stat: -rw-r--r-- 1,795 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
    README for pd external package 'pdstring'

    Last updated for pdstring v0.06

DESCRIPTION
    The 'pdstring' package contains objects for converting to and from
    (ASCII)-strings, represented as lists of floats.

INSTALLATION
    Issue the following commands to the shell:

       cd PACKAGE-XX.YY  (or wherever you extracted the distribution)
       ./configure
       make
       make install

BUILD OPTIONS
    The 'configure' script supports the following options, among others:

    * --help
        Output a brief usage summary of the 'configure' script, including a
        list of supported options and influential environment variables.

    * --enable-debug , --disable-debug
        Whether to enable verbose debugging messages. Default=no.

ACKNOWLEDGEMENTS
    PD by Miller Puckette and others.

    Ideas, black magic, and other nuggets of information drawn from code by
    Guenter Geiger, Larry Troxler, and iohannes m zmoelnig.

KNOWN BUGS
  Memory Usage
    Encoding each byte of a string as its own float is shamefully wasteful:
    it uses only 1 byte out of at least 3 which could be losslessly used
    given ANSI/IEEE Std 754-1985 floats, not to mention the remaining
    byte(s) (usually 1) of the float itself or the (usually 4) bytes used
    for the a_type flag. Unfortunately, Pd trims some floating point
    precision in message boxes and in float atoms, so a truly lossless float
    encoding for Pd would only be possible using 2 bytes per float (wasting
    1/2 the space of the float itself), and (to me), the memory saving such
    an encoding would provide is just not worth the lack of transparency and
    additional workload it would involve (but contact me if you want the
    code anyways).

AUTHOR
    Bryan Jurish <moocow@ling.uni-potsdam.de>