Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Launchpad mk3 Virtual fader behaviour #437

Open
terminalstatic opened this issue Jan 7, 2025 · 2 comments
Open

Launchpad mk3 Virtual fader behaviour #437

terminalstatic opened this issue Jan 7, 2025 · 2 comments

Comments

@terminalstatic
Copy link

terminalstatic commented Jan 7, 2025

Hey Jürgen, I'm using the launchpad mk3 with your script a bit currently and found the Virtual Fader behaviour a little weird.
I cloned your repo and played with the VirtualFaderImpl. I found that whatever you do in line 206 messes the behaviour up and just deleted the whole thing. I didn't really experience anything negative (except that the fader behaves more normal now) but have no idea what this was supposed to be doing in the first place ;). I also removed the calculations in the moveTo method and substituted the array(yeah I know performance considerations) with an exponential function. Didn't really bother to figure out why the moveTimerDelay had to be calculated like this, I just set it equal (-1) to the moveDelay for now. Device will probably explode anytime soon now.

In case you're interested: https://github.com/terminalstatic/DrivenByMoss/blob/master/src/main/java/de/mossgrabers/framework/controller/grid/VirtualFaderImpl.java

I held back from doing a pull request because too many ambiguities :)

@git-moss
Copy link
Owner

git-moss commented Jan 7, 2025

Thanks for the info. Will have a look when I find some time. Without having checked anything, the additional code might be necessary for the other Launchpad versions.

@terminalstatic
Copy link
Author

Hi, there's another issue(maybe a feature for some ;)) which is when changing views while the fader is still moving it either continues to move the fader in the new view at the same index or continues moving the fader when getting back to a view that contains Virtual faders from a no faders view.

In my opinion the fader should either continue moving in the background(hmm... ;)) or at least stop moving when switching views.

I went for the quick fix.
In case you're interested I handled this adding a check to the change listener in the LaunchpadControllerSetup that checks if the previous view is an instance of AbstractFaderView, added a stopAllFaderMovements method to the LaunchpadControlSurface class, a stopFaderMovement method that sets a stop flag and a condition to the moveFaderToDestination method that returns if the flag is set to VirtualFaderImpl.

Files that contain the changes are:

https://github.com/terminalstatic/DrivenByMoss/blob/master/src/main/java/de/mossgrabers/controller/novation/launchpad/LaunchpadControllerSetup.java
https://github.com/terminalstatic/DrivenByMoss/blob/master/src/main/java/de/mossgrabers/controller/novation/launchpad/controller/LaunchpadControlSurface.java
https://github.com/terminalstatic/DrivenByMoss/blob/master/src/main/java/de/mossgrabers/framework/controller/grid/IVirtualFader.java
https://github.com/terminalstatic/DrivenByMoss/blob/master/src/main/java/de/mossgrabers/framework/controller/grid/VirtualFaderImpl.java

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants