projectM-visualizer / frontend-sdl2

Standalone application based on SDL2 that turns your desktop audio into awesome visuals. Available on most platforms supported by both libprojectM and libSDL2.
GNU General Public License v3.0
58 stars 32 forks source link

Customizable keybindings #8

Open EvanCarroll opened 5 years ago

EvanCarroll commented 5 years ago

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


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).

iamnkc commented 5 years ago

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.

ghost commented 5 years ago

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?

Chinmaygoyal commented 4 years ago

Is the issue still up for grab?

revmischa commented 4 years ago

yep!

Chinmaygoyal commented 4 years ago

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

revmischa commented 4 years ago

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)

shubhamrajeevpunekar commented 4 years ago

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?

ghost commented 4 years ago

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 notifications@github.com 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.

revmischa commented 4 years ago

@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.

ghost commented 4 years ago

Haha ok I will try to fix it

On Oct 16, 2019, at 4:28 AM, Mischa Spiegelmock notifications@github.com 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.

shubhamrajeevpunekar commented 4 years ago

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

@revmischa, I had the following questions:

revmischa commented 4 years ago

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

shubhamrajeevpunekar commented 4 years ago

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?

ghost commented 4 years ago

Greetings @srp3003

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

image

gdstewart commented 4 years ago

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".

theIDinside commented 2 years ago

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;

revmischa commented 2 years ago

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

EvanCarroll commented 2 years ago

@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.

revmischa commented 2 years ago

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

kblaschke commented 2 years ago

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 commented 1 year ago

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 commented 7 months ago

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.