Cabbage Logo
Back to Cabbage Site

Hrange / vrange small graphic quirk (fixed)

#1

Just a small graphic quirk that arises if the initial values for the lower and upper handles are the same. In hrange they are initially drawn on top of each other. In vrange they are invisible. Moving either of the handles rectifies the problem. Here’s a test:

<Cabbage>
form size(420, 390)

hrange bounds(  5,  5, 400, 30), channel("1","2"), range(0, 1, 0.5:0.5)

vrange bounds(190, 50, 40, 300), channel("3","4"), range(0, 1, 0.5:0.5)

</Cabbage>

<CsoundSynthesizer>

<CsOptions>
-dm0 -n
</CsOptions>

<CsInstruments>
sr = 44100
ksmps = 32
nchnls = 2
0dbfs = 1

instr   1
endin

</CsInstruments>

<CsScore>
i 1 0 300
</CsScore>

</CsoundSynthesizer>
#2

Thanks Iain. I’ll take a look.

#3

Rather than start a new thread for other VERY minor graphical quirks with hrange, I’ll just tack it on over here. I noticed a few quirks, particularly when comparing to hslider… seems like (especially 1 and 2) should be fixed for consistency. 3 might be intentional and really isn’t a big deal.

  1. The total rendered width is different, even with the same bounds.
  2. The “tick marks” also don’t seem to render at the same places, but this might be a side effect of the first issue.
  3. The “handles” are rendered differently between the two, with hrange being a more squared handle and hslider being more oval.

Here’s an example that makes the differences pretty obvious: hrange_test3.csd (872 Bytes)

#4

I haven’t forgot abut this. I just got caught up with another issue at the moment that’s a little more serious. I’ll let you now when I get a chance to return to this.

#5

This is fixed in GIT now. I’ll run off new builds when I’m next in OSX and Windows. As you can see, all ticks line up, and I also fixed it so that the extreme left and right positions also match up those of regular h and v sliders. With regards to the different shapes of the thumbs, this was actually done on purpose so to easily distinguish the sliders. I was never a fan of the oval shapes for range sliders and you don’t get much contact when the thumbs are right beside each other. However, I may look at having the thumb vertical on the inside and oval on the outside. It might fit better to the existing ones.

[EDIT] I’m just uploaded a new Windows beta that has these changes in it.

#6

Thanks for all of this Rory, I think that these range sliders (and the encoder) are very useful additions.

#7

I’m still not 100% happy with the look of the encoder widget, but the functionality is there. That’s the most important thing. I’m still expecting you to hit a few snags with both of them to be honest. The range sliders are useful, but I find they are not great for very fine control. Btw, have you noticed the new velocity() identifier for sliders? That adds another level of fine control to slider movement.

velocity(val): Sets the sensitivity of the slider to mouse movement. The value passed should be in the range of 1 upwards. Note that velocity mode will only work if the range of the slider is greater than the distance in pixels between min and max.

#8

The effect of velocity() seems quite subtle. Or maybe I just don’t have the motor skills to move the mouse tiny distances. I remember that velocity was a specific request from a user.

I don’t mind the look of the encoder, but maybe it could have a dot indicator rather than a wedge? It does seem to jump in steps a bit, and this is more noticeable the bigger the widget is. This might be preferred however, as the idea with an encoder is that it can be incremented in steps without having to strain over making micro mouse movement. For times when a user wants smoother movement (and smaller steps) maybe a velocity() identifier could come into play?

Slightly on the same topic, is it possible to modify the behaviour of rsliders that use extreme values for skew so that the pixel steps are even? E.g this one:
rslider bounds(10,10,100,100), channel(“rslider”), range(0, 1, 0, 0.125)

#9

I’m afraid it would be a lot of work to implement this. I’m lucky to be able to use some JUCE methods for this stuff. Hacking it would be a can of worms that I’m not that interested in opening! But please try to convince me otherwise if it is really something that is important to you :wink: