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