Dynamic Number Slider

Replies to This Discussion

Permalink Reply by peter fotiadis on May 24, 2014 at 12:01am

I totally agree.

Permalink Reply by David Rutten on May 24, 2014 at 2:30am

It has been discussed before, and since we're discussing it again, I'll ask the same questions again:

• What value do I display on the slider if you supply more than one domain?
• If you supply several domains (or more than one accuracy), how do I deal with the fact that some slider positions are only valid for domain A while others are only valid for domain B?
• What happens to an existing slider value when the domain changes? Does it try and stay the same as best it can? Does it reposition itself at the same percentage?
• What happens when you provide a singleton domain?
• What happens when you go from a singleton domain to a valid domain again?
• What happens when you provide a reversed domain, should the slider flip the extremes or should it go backwards?

--

David Rutten

david@mcneel.com

Permalink Reply by Ale Inno on May 24, 2014 at 3:57pm

Thank you David for your patience, for your time, and for always staying open-minded and willing to listen to us!

I have a "mental picture" in my mind, a kind of component I have been dreaming of in the last nights, let me try to describe it:
-disclaimer: I'm an industrial designer, my coding experience can be compared to your, when you were 4 year old :)
-disclaimer 2: I did a picture at the end of the post that maybe explains more than my words

the component has 2 inputs (Start Value, End Value) and one output (Picked Value)

this phantomatic component (which I would refere to as "dynamic value picker") supports any amount of domains on every input -> it works as if they come grafted, from a "longest list" component

The component "at rest" shows only one slider -with question marks on both edges-

For every couple on inputs you connect (1 Start Value connection + 1 End Value connection) it would visually generate a new slider (exactly like a "number slider" component)
main difference from the "number slider" component, this one would show the Start Value and End Value numbers at the edges of each thus generated slider

Right click -> edit on it would recall a window similar to the "number slider", with the main difference that only the first part of those options would be present (see attached image for clarity)
Whatever slide accuracy you set, it will affect the whole "dinamic value picker" phantom component (if you set "integer numbers" and for any reason one or more inputs are "floating points numbers", the component automatically rounds the inputs to the best "Integer", and allows you only to pick integer numbers in-between)

If you suddenly change a "Start Value" or an "End Value" input, the affected slider/sliders in the component will try to stay as close as possible to the same % value they were before (example if the domain was from 5 to 11, integers only, and you first picked the value 8, the slider was exactly in position 50%: when you change the End Value domain to 21 the slider will set itself to 13 - yes, I picked an easy one lol )

When you first plug a couple of Start Value + End Value, the slider sets itself to Picked Value = Start Value

It could also be possible to supply negative values as Value End and positive values as Value Start: the slider let you pick a number on that domain regardless of the numerical order you use

Last thing, but it's just fancy imagination, if you zoom-in the output (Picked Value) connection dot, a little - and + appears (like in other common components), letting you add a new cursor to every existing slider (it could be possible to customize the color of the new cursor to avoid confusion)

This is the exact description of what I would ask to the lamp genie :)

I attach a pic I just did, in the hope to better explain myself: picture link

and of course thank you again for reading this long poem!

Permalink Reply by David Rutten on May 24, 2014 at 5:20pm

Ok, thanks for the extensive explanation. Your request is somewhat different from other slider-input requests I've had so far. I do have two follow up questions:

1. Wouldn't it make more sense to put all the values a single slider generates into a single list, rather than creating a new tree branch for each one?
2. Would it be useful to have a separate output for each slider, instead of a single one?

I can tell you now that the slider core class does not support multiple grips, so adding this would require a significant amount of shoe-in code. It probably won't happen for GH1. The remainder of your request is possible with existing code, but still quite a lot of work. I'll let it sit here for a while to see if many people agree this would be a useful object to have.

--

David Rutten

david@mcneel.com

Permalink Reply by Ale Inno on May 25, 2014 at 9:34am

hi David,
yes to both your observations, you are right

for sure having a separate output for each slider, instead of a single one for all the values, would speed-up the integration of this component in any workflow

-> would it make things easier if the component could accept only "pre-built" domains as inputs ?

in my mind I see extensive use of such a component for splitting lists, "debugging" definitions (maybe coupled with list-item) and all thae situations usually require the domain of a number slider to be manually set again

I think it might also make definitions "more adaptive", letting them work in different situations with less ad-hoc customization needed (I would use this component instead of a classic number slider in at least 75% of the situations)

I also imagine I would almost always use this instead of number sliders coupled with remap-numbers components

would it be helpful if I create a kind of detailed list of "situations" where the use of this component would save time and make new kinds of definitions possible?
(maybe all this stuff goes on just in my mind, but I really see new horizons with the creation of this thing)

Permalink Reply by Dan Hou on August 18, 2014 at 9:43pm

Hi David,

Ale' idea is just what I want. I think this ideal component is very useful to design dependent variables in optimization. Is there some way to realize it? If by programing, is it difficult? Where can I find the original script of slider?

Bests,

Dan

Permalink Reply by David Rutten on August 19, 2014 at 3:48am

It will involve a lot of interface code, but it's totally doable. I think I'll need 3 solid days to code this up from scratch, and that's assuming nothing goes wrong.

--

David Rutten

david@mcneel.com

Permalink Reply by Dan Hou on August 19, 2014 at 7:58am

Hi David,

Thank you for your effort. Looking forward to this new component. I urgently need it because my paper related to optimization will be submitted by the end of this month. Without it, I have to make constrains on the variables which are mentioned in another discussion. There are two many constraints, which definitely hinder the optimization process and cost much time.

Bests,

Dan 

Permalink Reply by Arend on August 19, 2014 at 2:22am

Agreed, would be a great idea, (although this images starts to be come confusing with multiple handles, and tree output).

I would see great usage in this as a configurable gnome pool.

Permalink Reply by Ale Inno on August 20, 2014 at 7:48am

I see some hope here :)

Permalink Reply by peter fotiadis on August 20, 2014 at 8:03am

Permalink Reply by Santiago Diaz on July 24, 2015 at 5:08pm

How about inputting domains?

I was too lazy to change the numbers and shape position in the image below, pretend that the first is 0.250 To 1.000, the next is 0.400 To 1.250, etc.

Not the same versatility as inputting lists. But I'm not sure I'd benefit much by inputting lists, to be perfectly honest. At least for those whom use the remote control panel, this could be an easy way to keep 'related' sliders in the same slider group.

• ‹ Previous
• 1
• 2
• Next ›
• Page