Talk:Completed: Proposal Binding Effects to Hot-Keys

From Audacity Wiki
Revision as of 19:06, 4 January 2012 by Edgar (talk | contribs) (ed note)
Jump to: navigation, search

Ed 1Jan12: I really do not like the proposed "Details"!

    • Peter 4Jan12: That's because I had to struggle to infer what you meant purely from the graphic image of the GUI <grins>. Should be better now.
  • -1 limiting number available--hard to code and hard to explain "Why?"
    • Peter 4Jan12: ok I have removed that restriction.
  • -1 on/off switch/checkbox to "indicate which keys are to be bound to effects"; the checkboxes in my picture control "display in menu" and an effect could be used via hot-key even if not on the menu
    • Peter 4Jan12: You've confused me here Ed. I now don't understand what the tickboxes at the left are for. Surely you don't mean them to be used to turn effects on/off or make them available/unavailable? Can you clarify please Ed.
      • Ed 4Jan12: The checkbox controls only adding the item to the menu, if checked it is visible (the default & current behavior); if not checked there is no menu item but the effect is still loaded and available to Batch Processing or application via its assigned keyboard shortcut. This allow the savvy user to only have items of rare use on the menu and use the keyboard to deploy frequently used plug-ins.
  • -1 "Preference page called "Effects Keyboard Shortcuts" my bad <grin>, too long; I was just using it as a test of something else and for emphasis--try "Effects Shortcuts" or "Effects Keys" and get some feedback from the forum before deciding; not only that but I believe it should be a "tab":
    • Peter 4Jan12: ok I have shortened the name to "Effects Shortcuts". @Ed: do you think you might be able to find sometime to update the image?
      • Ed 4Jan12: I could but lets await further discussion in re. tabbed panel and any other label options. Note that tabs may not be supported under ShuttleGUI as of now.

TabsDemo.png (image photoshopped--not actual code)

    • Peter 4Jan12: ok I have added the "Tabs" version as an alternative version. @Ed: do you think the text on the second tab should be changed to "Effects Shortcuts"?
      • Ed 4Jan: No, the current single panel's title is a verb-object pair and the additional panel should conform grammatically.
  • -1 "Two radio buttons to be provided for each effect...If neither is checked "on" then using the assigned hot-key will invoke the dialog for the effect enabling the user to set the parameter values to be used" IMVHO this would be very bad design and with radio buttons one must always be on. It would require 2 radio buttons and a checkbox which would control "execute without the dialog popping up"; I believe the dialog should pop up populated as the user wishes and that the "execute command" (OK) button be active (execute on <ENTER> key, just as it is now).
    • Peter 4Jan12: Ok, I have changed the details on this as you suggest.
  • -1 "Default to be no bindings assigned (I believe there is no really "typical" user)." At least one effect should have a default key (I suggest "Amp") so the ability is more discoverable.
    • Peter 4Jan12: ok done.
  • -1 "The assigned hotkeys will be inoperable if no audio is selected." Currently this is controlled by the Preference Tracks > Select all audio in project, if none selected (which BTW has a spurious comma) and I would leave it that way.
    • Peter 4Jan12: No, Tracks > Select all audio in project, if none selected just defines a manner of selecting audio. If you have that turned off as a Preference (I always do turn it off) then you can have no audio selected and in which case all effects should be (and are) inoperable.
      • Ed 4Jan12: True, but if ON (the default) the keys should still be operable (as are the menu items) even with no audio selected. I contend that the current behavior be maintained exactly as-is in this regard--we may just be having a failure of communications <grin> !

  • Also note that this new page would not work with the current GUI design of Preferences and relies on being able to re-size (beyond current limits) and/or scroll the dialog's contents (both of which are trivial to accomplish--code available from me).

Relevant discussion points from forum thread that initiated this proposal

Edgar 1Nov11:

Effects mapping to keys.png

This is real code but only built-in Effects are considered and only the GUI is implemented at this time. I have some ideas about how to install the shortcuts on the menu. I realize that post-2.0 the Developers have plans to add the Effects plug-ins to the Commands Manager – this should make managing their shortcuts a lot easier.

My interim solution allows the user to turn any Effect on or off in the menu, select whether the Effect dialog opens showing the default values or the most recently used values and, obviously, allows the association of the keyboard shortcut. It also creates a separate Preferences page – the Keyboard page is already very long.

This Preference page might also be an appropriate venue for assigning a category to an Effect.

Steve Daulton 1Nv11:

That looks really interesting Edgar.

Edgar 1Nov11:

I got a lot further this AM. Now, instead of hard-coding for the known built-in effects it reads all known effects and builds the pref panel from that. It is now reading the prefs from CFG when it builds the page.

[done]storing the values (I am editing the CFG file by hand right now); act on the stored values--not hard to code but a lot of new code;
change the "Effects Keyboard Shortcuts" page into a TAB of the "Effects" page (I have no idea how to do that!).

Solanus 2Nov11:

If your code can read from all known effects and populate that dialog, how hard would it be to read the contents of the Plugins folder and populate the menu drop-down - including using subfolders as categories?

Edgar 2Nov11:

Not hard at all--that is my ultimate goal.

I now have the ON/OFF switch working so the user may leave effects in the plug-ins folder and turn menu items On/Off even for built-in effects. Next will be to add keyboard shortcuts and categories will come last.

Edgar 2Nov11:

After putting a lot of hours into this I think I can now see why the Developers want to await a complete make-over to the effects code before addressing these issues. I keep hitting brick walls when it comes to implementing the user's choices in re. turning menu items ON/OFF, assigning shortcuts or moving items from one place on the menu to another. I think I am going to abandon this project for now. Maybe the GUI interface in Prefs can be a starting point for a Proposal discussion.