(Miguel Villegas Ballesta) #1

Lately I have been working with design space exploration and been in need of inputing sets of several values for a determined piece. Sometimes sets consisting of 20+ values.

I started using genepools to control this values, but the intrinsic nature of the genepools is for my understanding, to provide variation and not stability and control for each value.

After some disasters I resorted to orderly arranged groups of sliders. They work perfect buuuut… Wouldn´t it be nice to have a component that is capable of hosting several tens of sliders at the same time and ouptut them as ordered list or tree? Each slider should be “setable” independetly from the rest (as in individual sliders by double clicking) and the value range could remain constant for the whole set.


Can you provide an example where genepools aren’t working for you? In my experience, there hasn’t been cases where they weren’t enough (I typically have some mapping from the genepool values to the actual phenotype).

(Miguel Villegas Ballesta) #3

Is not a thing of malfunctioning but of UX.
You can not type individual gene values, for example. Genes are not numbered. Sliding “feels” not so smooth…


Ah yes, those are definitely concerns I’ve noticed as well (except, genes are numbered, no?).

(Miguel Villegas Ballesta) #5

I meant genes are not “nameable”…


I could imagine a “slider dock” being a useful component. So you could build up your sliders wherever you like, and them attach them to a dock which would have a list output.

(David Rutten) #7

I was thinking that if you drag one slider just above or below another slider and let go, they’d just sort of ‘glue’ together and become a multi-slider. Not sure about the most intuitive way to peel them apart again though.

The sliders in GH2 is already multi-slider-aware in that each slider can belong to a ‘bundle’ of sliders. Sliders in the same bundle will automatically adjust their layout dimensions to be consistent for vertical alignment. It’s amazing how much this contributes to the tranquillity of the UI.

(Miguel Villegas Ballesta) #8

The glueing, could happen as easily as if grouping a bunch of sliders (and just sliders) would reckon what they are and turn them into a bundle.

On the topic of layout, I couldn´t agree more with you about the tranquility, but right today I had to do something I guess should not be so unusual.

I set a bunch of n sliders, for asigning 0 to 1 values with 5 decimal points. As you might guess, the first one usually goes from 0.00000 to 0.10000, the second from 0.05000 to 0.15000 and so on. If set equally, at the end, they “draw” sort of a harmonious curve, BUT at the really fine tuning stage, and to make the most out of canvas space and not turn them into something monstrously long, I ended up reseting the range of each slider. Instead of all going 0-1 each went to around its value. Result, an ugly bunch of dancing points on the canvas, but as UX is a breeze as I actually click on the slider and drag it right and left while looking at the screen for evaluating the result.

BTW, when I try to click-drag the slider point and instead end up dragging the whole slider around the canvas is really irritating as I have to turn the gaze to the canvas a loos focus from the screen. Wouldn´t it be nice to be able to fix some components to the canvas?

(David Rutten) #9

I don’t think that’s the solution though. You can make the slider grip larger in the slider properties window, easier to hit. I think any dragging that happens on the slider rail area should just result in value changes rather than object moving.

Sliders are always awkward when they deal with really large or really small numbers. At least you can zoom in on GH sliders and get a lot more accuracy, but I agree that it is annoying. I’d love to hear some ideas about what could make sliders more pleasing visually when dealing with numeric ranges like (0.0000010 to 0.0000050).


While I can see the interest of multi-sliders, I feel that being able to control characteristics of the slider through inputs would also be really useful.
In particular, changing the range based on upstream computation would help me in some cases.
It can be done through hacking or with Metahopper, but I wish it was built-in.


I just posted a new suggestion in the “Datatrees in GH2” thread, and it’s fitting because that’s exactly a case where it would be useful to change the slider ranges dynamically :

I use this as a “Tree explorer” to check how my lists are structured and how the items in my lists are ordered.

If I could change the ranges of my sliders based on the various branch depths and list lengths, this tool would be even more convenient to use…and you wouldn’t have to implement it :slight_smile: