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
this is an extra step for the client to figure out (i already know im updating 'leetness' and 'grunt', but now have to look up which field it is..) 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..)
toxy uses a key->value structure so the message would look more like
x252115:1 #leetness 378.0 #grunt ugh
im not a fan of the # prefix either, (and requiring them all the time could bloat file-size and network bandwidth...but an optional method would be great) but like the idea of key-value hash..especially in terms of patch readability and dynamically updating attributes via msg..or from a client GUI (how do yo update a iemgui dynamically, deconstruct the fields into some crazy 15-element message?)
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 ";" !)
so my question is, are the new devel_'s GUI fields the same as pd's datastructure_gui fields? if not, why not? one of hte main reasons ive been hacking around with GUI stuff is i loved the _concept_ of the data-structure GUIs but realized it would need little snippets of tk or perhaps openGL to make the datastruct views more useful (and get better control data back). inveting yet another format is a great way to contribute to the confusion.. but i admit i am NOT a fan of this new msp(d)-0.39 w(0:100)(0-38) nonsense, what the heck is that?!?!
Hallo, notyves hat gesagt: // notyves wrote:
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 ";" !)
They are not really dictionaries as in TCL, Python etc., they are more modelled after "struct" in C (they even share the name). One important difference is, that you cannot extend a [struct] with a new field at runtime, whereas you can extend a dict/hash with a new key easily. (That's what hashes are designed for and structs are not.)
but i admit i am NOT a fan of this new msp(d)-0.39 w(0:100)(0-38) nonsense, what the heck is that?!?!
It's a way to let a float field be displayed differently from its value using linear interpolation and it's also used to enforce a constraint on the field's value's range. Say you have a [struct foo ... float w] then [drawpolygon ... w(0:100)(0:38) ...] will
a) let w only go from 0 to 100 and b) let w be displayed as going from 0 px to 38 px.
What is still missing here is an alternate way to display w: scaled, but *without* restricting w to the range 0 to 100.
Ciao
On Sun, 9 Oct 2005, Frank Barknecht wrote:
a) let w only go from 0 to 100 and b) let w be displayed as going from 0 px to 38 px. What is still missing here is an alternate way to display w: scaled, but *without* restricting w to the range 0 to 100.
it could use (0:) as meaning w>=0, (:0) as meaning w<=0, and (:) as meaning no restriction.
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sun, 9 Oct 2005, Frank Barknecht wrote:
a) let w only go from 0 to 100 and b) let w be displayed as going from 0 px to 38 px. What is still missing here is an alternate way to display w: scaled, but *without* restricting w to the range 0 to 100.
it could use (0:) as meaning w>=0, (:0) as meaning w<=0, and (:) as meaning no restriction.
Not quite: You would not know how to scale, as there is no input range given.
Ciao
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
-
Frank Barknecht -
Mathieu Bouchard -
notyves