active/default state/value handling to restore last known or default state values for certain running features like 'Beat Loop Size' & 'Beat Jump / Beat Loop Move Size ', and general support for 'hot-loops' loop memory length and locations metadata

[ghost]

Feature Description

TLDR:

• Hot-Loops (aka Memory-Loops) (metadata based support for memory loop: number, location, and length; basically like the how the hot cues are handled (tags written/read), but for loops and w/length)
• General improvement for State/Value recall for features upon application startup (of priority: Beat Jump size, Beat Loop size, there are likely others, etc.)
• (Adjacent to the previous point): Beat Loop Size value restored to an active deck's previous/default value (toggle in settings) once a new track is loaded in (currently, a track with custom beat loop updates deck's active beat loop values upon load, beat loop size value remains once a new track is loaded into the deck (assuming new track doesn't have values of it's own)
• Generic/Primary Beat-Loop size/location written as metadata to the track tags
• Generic/Primary Beat-Jump size/location written as metadata to the track tags

Perhaps a method which can get/set and return the active/default state and/or size values to a calling feature. Features can call on app startup, and as-needed during performance.

Okay, long winded:
LFG:
Mixxx could benefit by some features hold onto previously used values or state, or even had an Advanced Options pane within Preferences exposing some of the common parameter defaults which could be modified. (maybe gated by a 'advanced user' warning prompt).

additionally, Not sure if there is a generic metadata tag for beat_loop_size + beat_loop_start_location, and beat_jump_size which could be written to file if utilised during playback. i am guessing it's written into a library file somewhere, as the behaviour that a beatloop is set when a specific track loads which had previously used a loop, though upon the next track loading into that deck the previous beat loop size value is not restored if a track loads that hasn't previously utilised a beatloop, it just keeps the beatloop size of the previously played track...

furthermore, i can't wait to see beat_loop_n# memory points written and in use, sort of like the hotcues are currently written into tags. not sure how pioneer or the likes are tagging those values, but that is another attractive feature request.

rb for sure has loop memory cues for location and length, i would have to see if the data is pushed into tags or a local store, and/or observe how...

Also, there needs to be a cleaner way to manage user input context from the keyboard... for instance, if you are selected in the library with the mouse, you can then push spacebar to toggle big library, and generally interact with the keyboard shortcuts for other deck and mixer functions..... if you are in the search text box, or anywhere else (even if you go from text to blank faceplate of a mixer area), it doesn't respond (causing missed or delayed hotcue, play/cue, or other button pushes during performance), or just the general annoyance of still in the type field when you want big library, etc.

i digress, the TLDR is a cleaner read; see above :)

Cheers,

[ronso0]

Thanks for this report.

I think, in order to keep issues manageable, we should move the keyboard aspect to a separate issue.
I'll comment on that anyway:

Also, there needs to be a cleaner way to manage user input context from the keyboard... for instance, if you are selected in the library with the mouse, you can then push spacebar to toggle big library, and generally interact with the keyboard shortcuts for other deck and mixer functions..... if you are in the search text box

... you can hit Esc in order to focus the tracks table (or root view of the feature currently selected in the sidebar).
And keyboard shortcuts will work.

Indeed the keyboard UX can be improved.

even if you go from text to blank faceplate of a mixer area

Yes, it may be unexpected that clicking a blank, supposedly unresponsive area doesn't not remove focus from the currently focused widget as it does in web pages or other apps.
This has been installed (#2307) to no not steal focus when clicking controls (buttons, sliders, ...) so we have a somewhat hazzle-free mixed mouse / keyboard / controller workflow (library navigation with controllers relies on focus and (emulated) keypresses). At that time we (I) didn't look into making exceptions for labels, widget groups (potentially blank space).
I tried to fix this a few time earlier, but didn't succed. Will give it another shot.