Comment: There is no delay when opening plugins when pressing shift. There is no delay when opening e send effect with ALT+double click.
Best regards,
Johannes
Hello,
this is the expected behaviour, a comment from Development:
It is a standard wait for a double click. If a modifier key is pressed the double click wait is ignored. That key was added just for that purpose. Cubase’s behavior is to ‘open’ things with a double click: a part is opened into an editor on a double click not a single click. If there is no click wait time, then multiple selections would be hard to implement with standard platform rules.
<<<
The ref. number is CHEST-1795 - I’m pretty sure we have more than one entry about this, and more recent as well. I will add its ref. number as well when I manage to find it.
Hmmm,
It still has a bad feel. What buttons accept double clicks? Standard behaviour for buttons is instant response.
I can buy that opening a plugin by clicking the field around the button would have some quirks but not the actual "e"button.
best regards,
johannes
From that response, I get that buttons which open an editor accept double-click.
But I’m not aware of the underlying code and / or framework / APIs limitations, same for ‘standard platforms rule’ the application must adhere to.
This is still an open task and considered as a FR.
Best,
Well I believe standard usability behaviour of buttons in applications is [Click] → Response/Action.
Objects differ from buttons in that they CAN be selected with a single click and need a double click to open.
This is no biggie in terms workflow-slowdown, but it’s a quirk that just feels wrong and i’m not buying that it can be the expected behaviour for a button. Call it a design flaw rather than a bug, but don’t call it a feature that could or could not be changed.
Don’t know anything about the underlying API. Do I need to do that as a user of the software?
Best regards 
I’m so glad to have found this thread. I never knew about the double-click or shift-click approach to opening plugins instantly (without the lag). I’ve been troubleshooting my system for so long to get rid of this annoying delay, rolling back graphics card drivers, changing power settings–everything under the sun. I never would have imagined this was designed on purpose. Weird!
This is extremely counter-intuitive compared to how most programs function. I’ve never had a program intentionally trigger a delay before completing the action and I really can’t wrap my head around the explained purpose. As a simple solution: Why not let the single click–the action most of us will use when working quickly–trigger the fast plugin open, and the shift-click be the laggy one (to fulfill whatever arcane purpose that may be)?
This is no doubt kicking you support requests you don’t need and causing frustration to everyone else out there like me who wouldn’t imagine a developer would program intentional lag into buttons.