[PD-dev] data "fields" - pure enough?

[Mathieu Bouchard]

On Sat, 8 Oct 2005, notyves wrote:

> wondering what mathieu's 'fields' addition to m_pd.h is to look in
> practice..saw a mention of 'bitmask', does this mean an incremental
> update of say, the 2nd and 5th attributes woudl look something like
> this?
> 
> x252115:1 update 010001000 2.45555 rofl

Yeah, something like that is a possibility I'm considering. The
differences are small:

 * the formatting we use for the objects is now just an hex code. (Where's
   this ":1" suffix coming from?)

 * you didn't write "1" in the right positions no matter whether I try
   0-based, 1-based, from left and from right. I don't think I'd use 
   binary code. I could use hex or decimal but it doesn't matter because 
   the client just has to do [expr $x & (1<<4)] to get bit #4 and such...

> this is an extra step for the client to figure out

The "fields" section already exists client-side in desire.tk and impd. 
It's there so that object constructors may be parsed client-side.

> and continues the tradition of unreadable patches..where you have to get
> out some kind of field reference, proably only existing in the pd source
> somewhere, to decode it.. ( i mean sure, x y the first couple are easy
> but then it rapidly descends..)

do this in the Tcl box:

  global fields; lindex $fields(bng) 5

and try out several possibilities instead of 5.

> x252115:1 #leetness 378.0 #grunt ugh
> im not a fan of the # prefix either,

we do not need #-prefixes because args will always alternate between keys 
and values.

> but an optional method would be great

I have nothing against making both possibilities available. Switching
between them would be changing two lines of code in the server, or so.

> client GUI (how do yo update a iemgui dynamically, deconstruct the
> fields into some crazy 15-element message?)

Well, in case of nbx,hsl,vsl, it's more like a 23-element message...

and in impd, it's exactly how it's done: the object gets deconstructed (in 
the sense of calling a t_savefn) which produces a message just as in a 
*.pd file.

> from a brief glance it looks like miller's data structures use a
> key-value idea, at least from the users standpoint, i mean [set
> template3 h] is exactly how youd do the same thing in tcl: [dict set
> template3 h 10].. and are converted to raw fields of data (seperated
> with escaped ";" !)

To me there are some differences:

* In a struct, the keys have to be predefined and a certain sequence of
  keys is given a special name or pointer that is used to categorize the
  structs and the names of their allowed keys.

* In a struct, fields are ordered, and so may be numbered by their
  positions.

I say, there are a few advantages to structs: size, speed, validation of
field names, and the ability to choose an order based on human factors
rather than alphabetical.

Actually, ObjectiveTcl would be much more efficient if lists with fixed 
field names were used. It's easy to implement structs using arrays, if 
fields have a fixed size.

Incidentally, in PureData, fields have a fixed size. AFAICT, they are of
type t_word, which doesn't include the a_type information. Each field def
(t_dataslot instance) has a mandatory type attached to it, which is not
the A_* series, but instead DT_FLOAT, DT_SYMBOL, DT_LIST, DT_ARRAY. There
is no DT_POINTER. There is also no DT_ANYATOM because t_atom is bigger
than t_word (as of now; I know a few ways that they could be made the same
size, but that's another topic).

> so my question is, are the new devel_'s GUI fields the same as pd's
> datastructure_gui fields? if not, why not?

well, there are many reasons, but just to give you two, t_scalar is 
neither a subclass nor a superclass of t_object. It's prolly workable, if 
there's code that can handle both t_scalar and t_array, as they would use 
a t_word[] array directly, and it would be possible to replace most of 
t_slider by a big t_word[18] for instance (note: that's the 23 I said 
before, minus the #X obj, the position, and the classname)

> inveting yet another format is a great way to contribute to the
> confusion..

I didn't mean it, I never used them "data structures", so it didn't spring
to my mind much. I was intending to use t_atom, which is almost the same
except:

 * it takes twice as much RAM server-side (not an issue)

 * doesn't do mandatory type-checking (not an issue either: see
   pd_scanargs)

 * maps directly to the natural notation for a pd list (neat!)

Anything I'm missing ?

____________________________________________________________________
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
Freelance Digital Arts Engineer, Montréal QC Canada