[PD-dev] atom types: extend or abuse?

Krzysztof Czaja czaja at chopin.edu.pl
Tue Nov 11 19:52:50 CET 2003


hi all,

I would like to gather your views about ways of either extending,
or abusing the set of Pd atom types, making it possible for pure
data objects to pass around arbitrary data.  This data would
likely be shared with out-of-Pd world.  Some ways I am aware of
are listed below with comments.

1. Supporting application-specific atom types.  There is no such
support in Pd, currently.

2. Introducing one new atom type, generic and extendable.

3. Using numbers as pointers or indices.

3a. Plain memory addresses (gridflow?).  Validation is possible by
placing a header with a magic word at an address.  However,
representation of an address does not fit into one Pd atom, is
clumsy (particularly when maintaining 32/64-bit compatibility),
and involves an overhead, possibly significant in some
applications.

3b. Indices into a pool (pdp).  In order to make validation
possible, another selector-atom is required (by looking at an
index-atom alone one cannot tell, if sender meant it to be an
index).  Maintaining a pool is unnecessary burden for some
applications.

Neither 3a, nor 3b, is a flexible one-atom solution.  Data
references have to be wrapped in Pd messages of a special format.

4. Using symbolic references (jitter).  This is, basically,
a variant of 3b.  It requires a special message format.

5. Using fake-symbol tags (upcoming `plustot' external).  These
are just symbol pointers, but instead of being hashed in the Pd's
symbol table, they live purely in an application domain. The
application-specific data is attached to the t_symbol `base'
structure:

struct _faked { t_symbol f_base; <application-specific-fields> };

where f_base.s_thing and f_base.s_next are always zero, and
f_base.s_name is the validation tag.

Fake-symbol pointers may be packed into lists, used in triggers,
etc.  For any object not aware of their special status, they
represent ordinary symbols (except for some malicious objects,
like settable receive).

They are serialization-friendly, in the sense, that tags could be
registered as providing special hooks for binbuf read and write
operations, once such hooks are supported.

Krzysztof





More information about the Pd-dev mailing list