Open CaMeLCaseError opened 11 months ago
There is already a control to set a hotcue regardless if it was set previously [ChannelN],hotcue_X_set
Set hotcue X to the current play position. If hotcue X was previously set, clears its hotcue status. https://manual.mixxx.org/2.3/chapters/appendix/mixxx_controls.html#control-[ChannelN]-hotcue_X_set
This can easily by added to the hotcue menu IMO. Move the playhead to the desired position, open the hotcue menu, click re-set.
The difficulty here is to map it on controllers: official skins and most controller mappings use [ChannelN],hotcue_X_activate
(set if not set, else go to, longpress to preview) and there's usually only one modifier available (Shift) which is used to trigger hotcue_X_clear
.
So, if you manage to introduce another modifier you can simply bind hotcue press to hotcue_X_set
.
FWIW I also need to re-set hotcues occasionally (using a controller) and I'm okay with clear + set to new position. Simply because I didn't find a nice way to map hotcue_X_set
, or rather: clear + re-set is way easier than utilizing any other button as modifier and make my mapping more complex .
Adding new controls hotcue_shift_earlier/_later
is also conceivable. The engine finds the closest (or last activated?) hotcue and shifts it by small steps like beat_translate_earlier/_later
.
That could be mapped either to +/- buttons or rotary encoders.
A very natural feeling for correcting it would be to press and hold a hotcue button, sliding the song pointer left and right to its desired position
Press and hold is currently triggering the hotcue preview. Implementing a mode switch to toggle regular set/recall or adjust mode is certainly feasible, but again: the difficulty is to find an accessible implementation for both skins and controller mappings.
Adjusting the loop boundaries #10658 is a similiar use case, and equally hard to implement IMO Also related: #9968 Ability to shift/swap the number of hotcues
There is already a control to set a hotcue regardless if it was set previously
[ChannelN],hotcue_X_set
Set hotcue X to the current play position. If hotcue X was previously set, clears its hotcue status. https://manual.mixxx.org/2.3/chapters/appendix/mixxx_controls.html#control-[ChannelN]-hotcue_X_set
cool. thanks for mentioning it here. it seems to save many lines of code for this purpose :)
This can easily by added to the hotcue menu IMO. Move the playhead to the desired position, open the hotcue menu, click re-set. The difficulty here is to map it on controllers: official skins and most controller mappings use
[ChannelN],hotcue_X_activate
(set if not set, else go to, longpress to preview) and there's usually only one modifier available (Shift) which is used to triggerhotcue_X_clear
. So, if you manage to introduce another modifier you can simply bind hotcue press tohotcue_X_set
.
hotcue_X_set
seems the easiest solution of all :) and yes. an additional modifier is definitely necessary. I'm pretty happy about the current behavior for long presses. it allows very musical playing of the hotcues and I'd not want to break this.
FWIW I also need to re-set hotcues occasionally (using a controller) and I'm okay with clear + set to new position. Simply because I didn't find a nice way to map
hotcue_X_set
, or rather: clear + re-set is way easier than utilizing any other button as modifier and make my mapping more complex .I also agree it becomes very fluent to move hotcues with the existing interface. If i have the time I'll try to add a modifier to directly adjust hotcues and test it.
Adding new controls
hotcue_shift_earlier/_later
is also conceivable. The engine finds the closest (or last activated?) hotcue and shifts it by small steps likebeat_translate_earlier/_later
. That could be mapped either to +/- buttons or rotary encoders.
i like the idea of beat_translate because you can already use the hotcue in a performance and do fine adjustments "on the fly". addditionally to "later" and "earlier" it could also take an argument which is the amount of time to go forward or backward.
A very natural feeling for correcting it would be to press and hold a hotcue button, sliding the song pointer left and right to its desired position
Press and hold is currently triggering the hotcue preview. Implementing a mode switch to toggle regular set/recall or adjust mode is certainly feasible, but again: the difficulty is to find an accessible implementation for both skins and controller mappings.
I'd also prefer press and hold with a modifier pressed initially. On several of the hercules controllers I tested there is a "hot cue" button that changes the internal layers of the controller so pads become hotcue pads. The same "hot cue" button" also notifies mixxx that it has been pressed. So it could be also abused as a modifier for the wheel or the +/- buttons.
e.g. to modify hotcue_12
Adjusting the loop boundaries #10658 is a similiar use case, and equally hard to implement IMO Also related: #9968 Ability to shift/swap the number of hotcues
the 2 controllers I have also use a "loop" button that could be used in a similar manner to act as a modifier for the loop start point. No idea about the end points though. I'd be really happy about continuously adjustable loops to create some glitch effects...
FYI As I mentioned I'm also looking for a solution so I went ahead and added the shift controls, hotcue_X_shift_earlier
/_later
. The offset is the same as with the beats_translate controls.
I'll open a PR soon.
Though IMO these controls are more suitable for the hotue menu, or custom skins I think, not really for most 2-deck controllers with limited buttons and modifiers. For my purpose (and yours IIUC) it'd be more helpful to have ONE set of controls (earlier/later) to adjust the closest hotcue, that can be mapped to an encoder (+- ticks) or a pair of buttons on some second/third layer. I think that could work well assuming hotcue adjustment happens while the track is stopped (to focus on a specific hotcue and avoid confusion with other hotcues).
The more I think about it, I might adopt my 'loop adjust' script function. It is what you suggested initially: press+hold loop_in/_out button and turn the jogwheel to adjust. With hotcues it may work accordingly if I take wheel touch into account:
¹I'll need to verify this
Though this would be only a very specific controller impementation which won't help much with existing mappings I'm afraid since users would need to have a custom hotcue function (or component when using components-js).
I'll let you know if I can get it to work as I imagine.
I'm wondering; why not have a cue_N_shift_earlier, for, like, the primary cue.
Being able to bind shifting hotcues, intro/outro starts/finishes, and beatgrid alignments with to MIDI encoders is and would be nice, so being able to do the same with the primary cue point takes this full circle.
Having to set the main cue with a main platter jogwheel (with it's momentum) with the use of the main playhead position and then pressing a button is kinda complex in comparison. Just being able to rotate an encoder for that cue would also be handy.
Sure it can be added for any cue.
I'll revisit #12372 and check whether there's a smarter way to move the closest / last-used cue (of any type) than the one I already tried.
It is also possible to create playposition_move
/_move_small
so one can use the existing cue controls + one encoder or two buttons to move / re-set cues.
Feature Description
While creating hotcues I frequently have to adjust the hotcue to come in a bit earlier or later than what I achieve when I tap one of the hotcue pads on a hardware controller or in the mix UI while playing.
To correct the "bad" hotcue I usually trigger the bad hotcue, then delete the bad hotcue, move the track a bit to the left or right and recreate the good hotcue.
I see 2 ways of correcting the hotcues more conveniently:
A very natural feeling for correcting it would be to press and hold a hotcue button, sliding the song pointer left and right to its desired position and when releasing the hotcue button the cuepoint is finally moved. To listen and decide where the hotcue should go you would basically "scratch" the point around the cue point until you hear where it should be. Pretty much the vinyl style of finding a cue point.
An other way of doing it would be to have "nudge buttons" that nudge the most recently used hotcue left and right. Listening is then done by repeatedly pushing the hotcue. This would be more the Digital-DJ way of finding a good point for the hotcue.
Is this something that should be implemented controller specific? Or should mixxx's interface also include these controls for mouse and keyboard use? Is there something I have missed that does this already?
(btw: I'm not sure if audio latency is often the cause for "too late hotcues" or this is simply me being too slow or too fast ;)