[PD] definitions of data types

Hans-Christoph Steiner hans at eds.org
Sun Feb 12 23:22:00 CET 2006


On Feb 10, 2006, at 5:09 PM, Mathieu Bouchard wrote:

> On Mon, 6 Feb 2006, Frank Barknecht wrote:
>
>> I just wanted to avoid calling it "symbol", which of course would be  
>> the
>> proper term, but is very confusing when you want to differentiate it
>> from the symbol-symbol (Hi, Alice!.) Using "word" is used as a casual
>> term here, intended to be understood by artists, not computing
>> scientists. ;)
>
> Even among comp.sci. and programmers, "word" doesn't have a consistent
> definition. Some define it as a 16-bit integer, some define it as an
> integer the same size as the main registers of a computer, and then  
> which
> ones are the "main" ones is debatable. That's just one usage of the  
> "word"
> word! Then there is Forth, in which "word" means like "atom" in Pd. In
> parser theory it may mean "single letter" (i'm not joking!).
>
>> Yes, you can [pack] pointers just fine. Btw: "Pack" could be an
>> alternative name for a list-message.
>
> That sounds like a good idea worthy of investigation.
>
>> [route] and [select] only deal with the other types of messages,
>> however there is a [trigger pointer] and [t a] also passes along a
>> pointer.
>
> Yes. For all practical purposes, there are three stable atom types, and
> then a bunch of extras. In the not-too-periodic table of the atom  
> types,
>
> stable:         A_FLOAT    A_SYMBOL A_POINTER |
> virtual:     A_DEFFLOAT A_DEFSYMBOL           |
> radioactive:   A_DOLLAR   A_DOLLSYM           | A_COMMA A_SEMI
> ----------------------------------------------+---------------
> bogons: A_NULL A_CANT A_GIMME
>
> In which "stable" and "radioactive" are the only ones actually  
> existing,
> and the others are cases of trying to shove too many features in
> t_atomtype.
>
>> I see data types in Pd slightly different. Defining data types would
>> also need to take GemLists or PDP-packets into account.
>
> Those are message-types, and GF's "grid" is also a message-type, but
> it's partially because pd doesn't support user-defined atom-types, so
> defining those things as message-types is a way around the problem.

data types and messages are separate.  So what's the data type for  
gridflow?  Well, in terms of Pd, grids are not made up of numeric  
atoms, symbolic atoms, or pointer atoms, so...

.hc

________________________________________________________________________ 
____

  As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously.
                                                   - Benjamin Franklin





More information about the Pd-list mailing list