Toggle button single click

McNeel,

What has happened with this behavior of the Toggle component?

2012

2018
image

Some regression of functionality :frowning:

Any ideas? Am I missing something?

I can’t remember that far back, but I imagine the component was split into two; Toggle and Button. Also the newer components can have values other than true and false associated with either state.

But can we get the option to single click toggle the booleans,

because the button is doing as follows:

  • press - toggle
  • release - toggle

I want the behavior:

  • click - toggle
  • release - do nothing

Same as if the button is left down. Think of it as one TV when TVs still had buttons on them :roll_eyes:
, to toggle Mute, the button stayed pressed down while muted then when pressed it came up again.
Currently the only way to implement that is using script

I remember the plug-in firefly had a “state” component that did something like that. I’m not sure this is the best way to do it, but this is a quick/dirty solution that mimics the state component from firefly, (and I think the behavior you are describing?)


GH file is in Rhino 6, but code should work in 5 or 6).

"""Provides a scripting component.
    Inputs:
        x: boolean button
        y: value to use in modf function, (in this case, change state based
        on how many times the button is pressed. input of 2 will always yield 0 or 1 result)
    Output:
        a: saved state
        b: number of times button has been pressed"""

__author__ = "chanley"
__version__ = "2018.08.22"
import scriptcontext as sc
import math

if not sc.sticky.get('foostate'):
    sc.sticky['foostate'] = True
    
if not sc.sticky.get('foocounter'):
    sc.sticky['foocounter'] = 0

if x:
    sc.sticky['foocounter'] +=1
    
b = sc.sticky['foocounter']
a = math.fmod(b, y) 

BooleanStateModulus.gh (5.7 KB)

Thanks @chanley,

What I do now is using variation of this:

But why the need to do that with scripting components?. Why not having it right there as a config of the button itself. It should not be that much coding to do it.

agreed, it would be nice to have included…but…as you said, it’s not that much coding to add the “feature” yourself!

The place where I found that type of feature the most valuable was when connecting external hardware/controllers into a GH def. Like…attaching a hardware button through some type of OSC listener, (mandrill was one, there are others I’m sure), and using the button to trigger something. It was one solution to dealing with a press and release event of a button, when we really only wanted the “press” event.

I got some stuff from here to play around with from here:

While fun…I kind of abandoned the exploration of it… I got it to work fine with GH, (turning knobs/sliders/buttons/etc…), but I wasn’t able to find a terribly meaningful use for it in my daily workflow.

::end sidetrack commentary. :slight_smile:

Add your ideas here: Grasshopper 2 Category or as a feature request to GH2 tag.

I believe this is not so difficult to be included in GH1 as it existed before (check the original post)

Unless, of course GH1 development is frozen, but I haven’t heard about that.

I intend to use it for toggling inputs, much faster than if I have to double click all the time. This could also start new iterations. One of my recent (and the reason I created this one), a button creating new guids, if it was just button no script behind it, PRESS = generate new GUID, RELEASE, generating another GUID, really annoying because I wanted only one, not two.

This is continuation of my previous threads where I am always discouraged to change component gui, by adding a button, like if it’s some kind of heresy

Unless, of course GH1 development is frozen, but I haven’t heard about that.

Just go to the link I sent and read the second sentence
" Grasshopper1 is now included in Rhino6+ and it is unlikely that, save for a few critical bug-fixes, any new features will be added to it. So even though Grasshopper2 isn’t yet available as a WIP product, any discussion about future functionality can be had here."

Don’t think difficulty is an issue, more about priority. Either way, can’t hurt to document the request in the appropriate place. Or don’t :man_shrugging:

Fair enough.

I see. Also, my statement of “not terribly useful” was intended towards the hardware knobs/sliders, not the actual functionality you were discussing.

One last thing…(again, not exactly what you want, but maybe close enough), would be a value list. Set the value list type to “value sequence”, and only have two values, (False-0, True-1).
ValueListSingleClick

:: hanley out :v:

value list thing is not a new idea/suggestion…as shown in the link that was posted in your other “wish” thread…

1 Like

Could you share the code and process you set for using Palette Gear? Thanks

sure…but I must admit, I can’t vouch for the reliability of this in any type of production environment.
The setup is as follows: (you will need mandrill, https://www.food4rhino.com/app/mandrill-midi-realtime-bridge-grasshopper)
1 - Start up/Configure Palette app
paletteExample
GH Connect.zip (508 Bytes) (this is the palette gear profile).
2 - open the mandrill executable and start the midi listener.
paletteExample_mandrill
You only start the First Controller
3 - Launch Rhino/GH and configure your GH def:


enable the timer on the mandrill component “Read Midi Device Data” to start streaming data.

This example is super simple. The slider controls the radius of the circle, and the button switches between planes.
mandrill_PaletteGearExample2.gh (18.8 KB)

Awesome! Thanks! I will test it out!

Andrew

It works. Thanks for the help.
Theo

Got it to work! Thanks for showing the setup and sharing the files. It took a little research to figure out how to set up a Windows Environment Variable for GHMandrill, but once I got that set up it worked great.

I found that to get the Pallet button to work a true/false required the Pallet setup to be ‘C - 0’, not ‘C - 1’ or ‘C# - 2’ .

Thanks again!
Andrew