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

Miller Puckette mpuckett at man104-1.ucsd.edu
Tue Nov 11 21:31:25 CET 2003


Oh, boy... this raises lots of interesting questions!

A few comments on individual ideas:

> 1. Supporting application-specific atom types.  There is no such
> support in Pd, currently.
> 
> 2. Introducing one new atom type, generic and extendable.

either of these first two would require adding code to dozens of 'switch'
statements both inside and outside Pd.  Some code would run
slower because of the extra cases to check.

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

I think 3a isn't really safe.  I don't understand why 3b requires
anything extra (you can just interpret numbers as indices and let
it just be wrong if someone gives you a wrong number.)  These _is_
extra work to do to check things when you get a reference to data
in a message.

Here's a variant (maybe) of 4: just make a hash table binding symbols
to objects.  Each separate extension could make its own hash list
and maintain its own name space.  You can generate symbols "x%d" to
name things that the user didn't name.

> 
> 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.
> 
That's interesting.  The only danger is that someone will want to compare
two symbols with the same name (but at different addresses) and get
badly confused!  Also, if you print a message out and re-read it it will
point to a different place; I'm not sure in how many places the "textability"
of messages really gets used...

And here's another possibility:
6.  somehow overload Pd's "pointer" structure to point to user-definable
data structures.  This would have the advantage of being compatible with
the way atoms are sent around Pd already, and the pointer type already
has a hook to protect against stale pointers.  The main disadvantage is
that the scalar thing is still quite "experimental"!

cheers
Miller




More information about the Pd-dev mailing list