Double Click - Love it!

Double click once, plugin GUI appears, double click again and it’s gone.

Great idea, no more of this back and forth just to view and dismiss a setting.

Now when it shows the “e” can we have a single click to disappear?

These shiny new buttons are nice but I think there needs to be some further functions besides on/off.

Otherwise a good start but the text needs to scroll in my view.

I personally hate having to double click to open editors, this is an Issue for me…

It’s the beginning of something special in my view.

Single click will return, SB can be counted on to re-implement things as requested and needed to temper the workflow for ease of use; of which there is copious evidence to support.

The question is, what can we imagine going next to the “e” symbol that currently only serves to show the status of a plugin window?

totally agree

But we can turn off, i.e. disable the plugin, so it follows that because the “e” is visible that eventually single click will be returned albeit with additional functionality overall.

hopefully english isn’t your primary language, as some of this stuff is hard to cypher. Anyhow, left click has been established as a horrible paradigm. Double click even worse. How many people do you know using a browser that rapidly click endlessly until something happens? I know a bunch. Also, clicking is a major contributor to RSIs. In other words, clicking is pretty much the worst workflow enhancement ever, both physically and operationally. Pretty much every application has gone to advanced keyboard accelerator functions, as these are much, much, much, much more efficient than using a mouse. There are acceptions of course (highlighting blocks of text for example, a mouse is ideal for that). Right mouse context menus are awesome … but they are there to get you to little used operations. There should be an accelerator for every menu item.

Anyhow, click = bad
doubleclick = really bad

I found this:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms646335(v=vs.85).aspx#_win32_Accelerator_Tables

So are you saying that SB is implementing point & click operations in deference to keyboard accelerators and/or menu functions?

Anyhow, click = bad
doubleclick = really bad

Yes but isn’t the complaint about something that will inevitably be rectified/improved as time goes on?

uh … no, it has actually gotten worse with C7. Shortcuts have been removed and many clicks have been added to existing operations.

Can I please ask you to catalog these in order to commence proceedings against SB :angry: :smiling_imp: :wink: :sunglasses:

Yes, this is exactly what I am saying. Not only that, their conceptual model for contextual keyboard control is extremely limited. It is primarily a global keyboard map.

why proceedings? There is no legal imperative here. Just my preference to use the keyboard over a mouse. What is funny is that the contextual model for touch is almost in parallel to the keyboard context, and both are fairly antithesis of the mouse model. It will be fun to watch as they try to get that figured out.

By this I am supposing you are talking about Key Commands?

About proceedings, I am having a joke.

I just thought it might be appropriate to commence a tirade similar to those of transparent events infamy or even the bit bridge crisis :laughing:

nah, I’m pretty even headed about it. I state my case where possible. But I use what I get.

I don’t know if menus are editable but I guess that would be a start…

not to mention ALT + SPACE for child windows.

I did notice that when selecting VST/Group outputs, that inspector selections remain the same regardless of track type so if you are on say “Equalizers” you can see each tracks’ status by using arrow up/down keys or the mouse, which wasn’t previously possible so to my mind this paves the way for keyboard accelerators to be implemented.