[PD] vbitmap

[Frank Barknecht]

Hallo,
Christopher Charles hat gesagt: // Christopher Charles wrote:

> ok. so now there is vradio-square look, banglike circles within a square 
> and toggle-like look. any other proposals? i changed it to frank's oval 
> variant, and for now i'm rather content with it, doesn't remind me too 
> much of bangs.

Me neither. I can follwo Mathieu's view that vbitmap is conceptually
similar to toggle, but I still like to ovals better for two reasons:
the toggle crosses are too hard to read anyways, and I would prefer to
have a really new graphical object - which vbitmap-oval only is to me,
because it doesn't look like bng to me.

> now for the functionality. are there any other ideas about this except 
> of expanding this to a 2-d bitmatrix (like blinkenlights). 

1) hbitmap ;)

2) bitmap's direction should be reversible. [vh]radio should be
reversible, too, actually. By reversible I mean a setable range
similar to the range of sliders, which can have the bigger value on
top or on the bottom (left or right with hsliders). 

(Actually both might be possible to do Once And Only Once with having
a 2d bitmatrix only.)

3) maybe: Make width settable independently. (Applies to [vh]radio as
well.) This would imply letting the square boxes become non-squares.

4) include it into the CVS on sourceforge. 

> i thought about implementing the option of having more states than
> just on and off. for example i could give each element 2 bits, so
> clicking on them would cycle through the 4 states (maybe represented
> by showing numbers or by in-between colours of back- and
> foreground). useful for different note velocities or probability
> maps in step sequencers. what do you think about this?

Like this: http://footils.org/cms/show/28 ? These were done using data
structures in front of a row of bng objects or in front of a vradio.
Clicking the squares cycles them through 5 sizes. It's a bit like
vbitmap actually, although with fixed dimensions and with indexed
access (send index, get current value at index pos.)

> 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.

Ciao
-- 
 Frank Barknecht                               _ ______footils.org__