On Tue, 7 Dec 2004, Frank Barknecht wrote:
Christopher Charles hat gesagt: // Christopher Charles wrote:
the other thing i was thinking about is the inlet behaviour: for now, it doesn't clip nor mod the value it sends to it's outlet(that's crap, for when you send a bigger value to the inlet, there is no graphical way to affect the bits which are out of range). i could either let it clip to 2^number-1, so in case a bigger number is sent, all bits would stay on. the other option (the one i'd prefer) is performing a modulo 2^number on the inlet. any other options?
I'd vote for clipping, as that is consistent with the IEMgui objects, and if someone wants modulo, it's still possible to add a [mod] in front.
the other iemgui objects don't work with bitfields. Float may be the _type_ in use, but the _interpretation_ of the numbers is different. With bitfields you are expected to use ^ and & in place of + and *, for example, according to Ring Theory ;-)
a slider clipping does min(b,max(a,x)) to keep x within [a,b].
the most used definitions of min and max for bitfields are:
x<y means x&y==x x>y means x&y==y
(side note: but it's not guaranteed that you have either less than, greater than, or equal. (see Partial Order Theory). then you don't have true min/max's, instead you have their cousins inf/sup, but let's still write it min/max)
usual bit definitions of min/max:
min(x,y) = x&y max(x,y) = x|y
the notion of bitfield intervals is pretty weird, so I will explain it only if really wanted, but let's just say we use [0,(1<<n)-1] as you say, but with the definition of min/max I have given. Then the clipping to that interval is (x|0)&((1<<n)-1), or just x&((1<<n)-1), which behaves exactly like x mod 1<<n.
So I think Chris is right (as in, his solution is more consistent).
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju