frontend-sdl2 icon indicating copy to clipboard operation
frontend-sdl2 copied to clipboard

Customizable keybindings

Open EvanCarroll opened this issue 6 years ago • 22 comments
trafficstars

I know this is somewhat petty, but I would love to have Vim-esque keybindings

  • H previous
  • L next
  • space play/pause (lock)
  • S shuffle
  • F11 maximize
  • I (instead of Ctrl + B)

Ctrl + R, M would be great without Ctrl


Ctrl+S and Ctrl+E make sense to me as is.


I wouldn't push something like this hard, but it just seems like that would make it a lot more natural for those of geeks that use with lot of other stuff. Right now I'm running i3 (vim), tmux (vim), vim (vim), ranger (vim), and vlc (vim).

EvanCarroll avatar Nov 28 '18 07:11 EvanCarroll

Hello, sir, I want to work on this feature. But, I am new to this. Can you provide some references so that I can start working on this feature.

iamnkc avatar Jul 10 '19 09:07 iamnkc

Greetings @n-k-chilagani The first step is building the software in your development environment. Are you able to build from the master branch? What operating system are you running?

ghost avatar Jul 20 '19 19:07 ghost

Is the issue still up for grab?

Chinmaygoyal avatar Sep 05 '19 10:09 Chinmaygoyal

yep!

revmischa avatar Sep 05 '19 10:09 revmischa

I am new to open source so it would be of great help if you could tell me where to start from.

Chinmaygoyal avatar Sep 07 '19 12:09 Chinmaygoyal

I would start here https://github.com/projectM-visualizer/projectm/blob/master/src/libprojectM/KeyHandler.cpp And then look at the specific app you want to play with (-sdl is a good choice)

revmischa avatar Sep 07 '19 13:09 revmischa

If this issue is still up for grabs, can I have a go at it? So far, I have been able to build the master branch code from source and the key bindings for switching to next and previous preset are working in projectMSDL binary. However, the bindings for showing help, fps or stats have not worked, in the code I wasn't able to locate the functions for displaying these either. Could you point me in the right direction?

shubhamrajeevpunekar avatar Oct 15 '19 19:10 shubhamrajeevpunekar

So you develop a strategic method for handling the needed changes. If you make a pull request on this repo, then myself and others can see your changes to make suggestions. Your changes do not have to be finished or working for you to open the pull request. The pull request creates a new ”ticket in the queue” for our continuous integration services. Most importantly: you have unlimited chances/retries to experiment with different ways to patch it. So there is no pressure to have a working patch to open the pull request. After your done experimenting, your patch must pass all the continuous integration tests. Then myself or one of the other devs here will merge your pull request. At that point you will become an official code contributor to projectm code. What do you think?

On Oct 15, 2019, at 3:55 PM, srp3003 [email protected] wrote:

 If this issue is still up for grabs, can I have a go at it? So far, I have been able to build the master branch code from source and the key bindings for switching to next and previous preset are working in projectMSDL binary. However, the bindings for showing help, fps or stats have not worked, in the code I wasn't able to locate the functions for displaying these either. Could you point me in the right direction?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

ghost avatar Oct 15 '19 20:10 ghost

@srp3003 sure go for it. Whatever is in KeyHandler.cpp is what is shared from the core library.

	case PROJECTM_KEYDOWN:

	  switch( keycode )
	    {
	    case PROJECTM_K_UP:
            beatDetect->beat_sensitivity += 0.25;
			if (beatDetect->beat_sensitivity > 5.0) beatDetect->beat_sensitivity = 5.0;
	      break;
	    case PROJECTM_K_DOWN:
            beatDetect->beat_sensitivity -= 0.25;
			if (beatDetect->beat_sensitivity < 0) beatDetect->beat_sensitivity = 0;
	      break;
		case PROJECTM_K_h:
 		  renderer->showhelp = !renderer->showhelp;
	      renderer->showstats= false;
	      renderer->showfps=false;
	    case PROJECTM_K_F1:
	      renderer->showhelp = !renderer->showhelp;
	      renderer->showstats=false;
	      renderer->showfps=false;
	      break;
	    case PROJECTM_K_y:
		this->setShuffleEnabled(!this->isShuffleEnabled());
		 break;

	    case PROJECTM_K_F5:
	      if (!renderer->showhelp)
		      renderer->showfps = !renderer->showfps;
	      break;

etc...

@coast77777777777 sounds great. i think the appveyor build is broken right now tho.

revmischa avatar Oct 16 '19 08:10 revmischa

Haha ok I will try to fix it

On Oct 16, 2019, at 4:28 AM, Mischa Spiegelmock [email protected] wrote:

 @srp3003 sure go for it. Whatever is in KeyHandler.cpp is what is shared from the core library.

case PROJECTM_KEYDOWN:

switch( keycode )
  {
  case PROJECTM_K_UP:
        beatDetect->beat_sensitivity += 0.25;
  	if (beatDetect->beat_sensitivity > 5.0) beatDetect->beat_sensitivity = 5.0;
    break;
  case PROJECTM_K_DOWN:
        beatDetect->beat_sensitivity -= 0.25;
  	if (beatDetect->beat_sensitivity < 0) beatDetect->beat_sensitivity = 0;
    break;
  case PROJECTM_K_h:
    renderer->showhelp = !renderer->showhelp;
    renderer->showstats= false;
    renderer->showfps=false;
  case PROJECTM_K_F1:
    renderer->showhelp = !renderer->showhelp;
    renderer->showstats=false;
    renderer->showfps=false;
    break;
  case PROJECTM_K_y:
  this->setShuffleEnabled(!this->isShuffleEnabled());
   break;

  case PROJECTM_K_F5:
    if (!renderer->showhelp)
        renderer->showfps = !renderer->showfps;
    break;

etc...

@coast77777777777 sounds great. i think the appveyor build is broken right now tho.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

ghost avatar Oct 16 '19 14:10 ghost

@coast77777777777, that sounds great! Especially your point about having unlimited chances really takes the pressure off!

@revmischa, I had the following questions:

  • which of the shortcuts should I try to implement?
  • Are Ctrl + B, Ctrl + R, Crtl + M, Ctrl+S and Ctrl + E assigned for some operation? I couldn't see any feedback on hitting them in projectMSDL binary.
  • Should I reassign "show help" to H instead of h? That will leave h and l free for previous and next.

shubhamrajeevpunekar avatar Oct 16 '19 19:10 shubhamrajeevpunekar

My advice is to mostly ignore the original text of this issue and do whatever is most compatible/similar to Milkdrop - http://wiki.winamp.com/wiki/MilkDrop_Unleashed_Guide#Usage

revmischa avatar Oct 16 '19 20:10 revmischa

I have attempted to update keybindings in PR - (I am creating a PR (Update keybindings similar to MilkDrop projectM-visualizer/projectm#262). Am I on the right track?

  • [x] BACKSPACE: return to previous preset (Modified an existing keybinding PROJECTM_K_n)
  • [ ] SPACE: transition to next preset (No projectMKeycode defined for SPACE)
  • [x] H: instant Hard cut (to next preset) (Modified an existing keybinding PROJECTM_K_n)
  • [x] R: toggle random (vs. sequential) preset traversal (Already implemented with PROJECTM_K_R and PROJECTM_K_r (hard cut))
  • [ ] L: load a specific preset (invokes the 'Load' menu) Not sure about how to invoke a menu, refreshing current_interface maybe?
  • [x] +/-: rate current preset (better/worse) Already implemented with PROJECTM_K_PLUS and PROJECTM_K_MINUS
  • [ ] scroll lock: lock/unlock current preset (keyboard light on means preset is locked) (prevents random switch to new preset) Need to add a projectMKeycode for scr lk
  • [ ] A: aggregate preset - loads a random preset, steals the warp shader from a different random preset, and steals the composite shader from a third random preset. TODO
  • [ ] D: cycle between various lock-states for the warp and composite shaders. When one of these shaders is locked, loading a new preset will load everything except the locked shaders, creating a mix between the two presets. TODO

shubhamrajeevpunekar avatar Oct 30 '19 19:10 shubhamrajeevpunekar

Greetings @srp3003

Can you review to verify that your implementation matches the classic milkdrop keybindings in this image?

image

ghost avatar Nov 04 '19 02:11 ghost

Hello, looking into this as something I could potentially contribute to. Is the plan to have a toggle to allow for multiple sets of keybindings? Or was the intention to switch over to the milkdrop keybindings? For example, I noticed that officially the "next" keybinding is still "n", and not "H".

gdstewart avatar Jun 20 '20 17:06 gdstewart

I don't think necessarily this should be considered a "good first issue" since it's actually pretty involved - but I'll take a dive into it. Just to be clear, what the issue is asking for, is;

  • configurability of the "events" that happen in the switch branch in KeyHandler.cpp right?

theIDinside avatar Oct 25 '21 15:10 theIDinside

I don't think this is a really needed feature but someone please correct me if they feel strongly otherwise.

revmischa avatar Oct 25 '21 17:10 revmischa

@theIDinside I believe that's correct.

@revmischa I like staring at pretty lines. I like vim keybindings. =) I'm not sure where need factors in on this project or any feature of it.

EvanCarroll avatar Oct 25 '21 18:10 EvanCarroll

Compared to all the other things that need fixing I would put this at the bottom of the pile of our issues

revmischa avatar Oct 25 '21 18:10 revmischa

I think a better solution would be that the projectM library itself doesn't do any keymapping/handling at all and only provide API calls for each functionality. This would leave the actual input handling - whatever this is - to the integrating application, e.g. projectMSDL. Some frontends may not even have a keyboard, but game controllers, TV remotes or other input devices for example.

I think most of the input actions are already handled by the C API, and KeyHandler is only an additional wrapper around these functions.

I'd give this a try and rework it, but removing the internal key handler will also break any applications using those, requiring a few code changes which IMO would be totally acceptable.

The SDL frontend could then make the keycodes configurable via the config file or any other means, possibly providing a few preconfigured hotkey settings (projectM, Milkdrop, vim) in the documentation/wiki.

The F1 help menu also needs to be updated by the external application, so I'd remove any key bindings from it, forcing the application to fill it in (projectMSDL already does that, so not much of a change here).

kblaschke avatar Nov 16 '21 10:11 kblaschke

An update to this old issue:

The built-in key handler in the library is soon gone, and the API mostly cleaned up. After the library is released as 4.0, I'll give the frontend a small overhaul and add a better UI, which should then finally allow users to rebind keys via both the UI and the configuration file, as we're only looking at SDL key handling and don't need a translation to projectM's keycodes anymore.

kblaschke avatar Nov 21 '22 21:11 kblaschke

With the key handler in libprojectM gone, the new UI I'm working on will get a key bind settings window. In this window, you'll be able to select from some binding presets (e.g. classic projectM and Milkdrop), but also define your own key bindings as well. Not sure if this will be in the initial stable release, but it's definitely a feature that will be implemented at some point.

kblaschke avatar Nov 27 '23 10:11 kblaschke