algorithmic modeling for Rhino
I know this topic has been already discussed in the past, but I'd like to give it another shot :)
I think a "secondary" number slider component with dinamic inputs (maximum, minimum, rounding etc) would definitely speed up the already awesome grasshopper workflow
The Remap component helps in some situations, but most of the time you have to manually change the range of number sliders (for instance, when the number of items is greater than the number-slider range)
What do you think about?
I don't have a lot of coding experience, otherwise I would code it by myself
I totally agree.
It has been discussed before, and since we're discussing it again, I'll ask the same questions again:
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!
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:
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.
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)
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?
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.
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.
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.
I see some hope here :)
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.