Add multiple functions (velocity, mod, chord, chord memory, ...) to sidebar pads in keyboard views (#255) - #901
Conversation
|
Awesome thanks! We were thinking of using one bar for velocity and the other for mod wheel (y in the mod matrix), I haven't reviewed your code yet but would that be a feasible option? |
|
@m-m-adams That's much better! Can do - this commit changes to that format and makes the min and max values adjustable (with pads corresponding to a linear range between the current min and max). |
| ModelStack* modelStack = setupModelStackWithSong(modelStackMemory, currentSong); | ||
| ModelStackWithTimelineCounter* modelStackWithTimelineCounter = | ||
| modelStack->addTimelineCounter(currentSong->currentClip); | ||
| ((MelodicInstrument*)currentInstrument()) |
There was a problem hiding this comment.
Is this cast actually safe? I know isometric explicitly doesn't support Kit, but is there some way to verify that the current instrument is a melodic instrument?
There was a problem hiding this comment.
It's not great since that could change in the future - the overarching class for all clips is "output" - you can check the type by accessing the type field here
DelugeFirmware/src/deluge/model/output.h
Line 53 in f7aaa2c
Another solution is just making an empty processParamFromInputMIDIChannel part of the instrument class, that would let it be implemented in future if mod wheel support is added to kits
There was a problem hiding this comment.
Added processParamFromInputMIDIChannel to instrument and kit
|
Hey there :) Great initative! I'm sure you already saw #255. Regarding implementation it would be great if most stuff is higher up than in isomorphic (for example in the layout interface |
|
|
||
| namespace deluge::gui::ui::keyboard::layout { | ||
|
|
||
| static inline void popupUint8(deluge::hid::Display* display, uint8_t val) { |
There was a problem hiding this comment.
This function is useful enough that I think it should live in the display class for convenience
|
Please, implement it as an "addon" (flexible, not hardcoded, so its functionality can be applied to any of the two columns) so we later can decide from a menu, which "action" we want for the left column of the keyboard view and which one for the right column. I would love this to be tweakable from the main menu so when more things are implemented (pitch bend, mod wheel, beat repeat), I can, as a user, decide to put Velocity on the right column for example, and Beat Repeat on the left column, and then I have my keyboard views the way I like. Other users may decide that they prefer to have modweel and pitch bend on those two columns... Flexibility would be neat |
|
That's easy enough to do in a follow on PR. I think once this is done on the KeyBoardLayout class instead of specifically isomorphic it's good to merge |
…opup(uint8_t), handle midi on instrument (noop for kit)
|
I actually missed #255 somehow 🤦 but I'll try to bring this more in line with the ideas there. I moved the code to an intermediate class ColumnControlsKeyboard instead of the KeyboardLayout (assuming other layouts may be developed that want to use the audition pads for something else) and added support to the In-Key keyboard. Modified the pad press logic to track held keys, but short press / long press is still TODO |
…ort press change, long press return to default
|
|
GENERAL IMPROVEMENTS: As an OLED user I would like to see the full name of the mode instead of the 4-letters abbreviation meant for 7seg users: And that's it. All my comments up to this one are what I found as bugs/considerations/suggestions from my testing. |
I can see the use for having things be temporary or the new normal, but I agree that the short-press / long-press seems a little unintuitive and the difference between short and long feels arbitrary. I'm fine with changing or scrapping it depending on what seems reasonable to everyone. I also thought it might be interesting to add a variable slew so that you could get smooth transitions between mod values.
Yes - this is the intended behavior. The keyboard's velocity is initialized to the instrument's default velocity, but from that point onward, the keyboard's velocity (both the immediate value and the set-by-short-press value that it falls back to) do not affect the default velocity used by the sequencer and are not affected by it. |
|
@soymonitus - thanks so much for all of this! I'm sure it's been frustrating and I'm sorry I didn't catch more of it myself, but I'm glad that you're willing to put in the effort. Keeping the quality of the community firmware up is massively important. |
|
I like the tap to latch/press to be momentary behaviour and it's consistent with performance mode. Found the mod wheel issue, it's the mpe y CC and not the mod wheel CC |
| case MOD: | ||
| if (pad.active) { | ||
| modDisplay = modMin + pad.y * modStep; | ||
| getCurrentInstrument()->processParamFromInputMIDIChannel(CC_NUMBER_Y_AXIS, modDisplay, |
There was a problem hiding this comment.
should be CC1 (mod wheel), this records it as MPE y to the currently sounding notes instead
There was a problem hiding this comment.
Actually looking again I think this is right as is, incoming CC1 is converted to this value. This should be fine
but then you cannot operate the modwheel for example as a real touchstrip modwheel, which is what I would expect from it, I mean, sliding my finger over the column to set a value, and don't want the value to jump back arbitrarily based on how fast or slow I did the slide (because some pad detected a short press vs other that detected a long press). Besides, if @robmccoll adds a slew then we would be in modwheel heaven, like a real touchstrip This two controls has nothing to do with performance view, they are different purposes |
- Fix missing check for dead pad presses - Adjustable SMOD pads to any scale - Change CMEM behavior to force clearing pads so you can play over it - Display::popup with long and short text for OLD/7SEG
|
Ok - this is probably ready for review again.
Hopefully the formatting is ok now - I'm having problems with .so resolution using the clang-format in the prepackaged toolchain so I used my own. Note: This is still using the short tap / long press. Also slew is not implemented. Where did things land on short press / tap? Maybe that could be turned on and off? Are there other UI options? |
|
Awesome I'll take another look! Regarding short/long press time this matches the rest of Deluge (performance view/sticky shift), so while there's some usability issues they should be addressed as a whole and it's not a problem specific to this PR |
|
You’ve got a conflict, can you merge in community? I believe you just have to keep both I think it will make the checks run too since it looks like this pr has an old version of the CI config in it |
m-m-adams
left a comment
There was a problem hiding this comment.
Awesome work, this is a ton of fun and the performance issues seem resolved. Thanks for the contribution!!
|
This works much better than when i first tested. However, i still think that velocity and modwherl should work differently, by not having a different behavior for long and short press, only short press, so you can slide your finger to change values like a touch strip |
|
Is it possible to record external midi input as a chord memory? |
|
The normal mute pads allow you to exit out of menus immediately, even a couple of layers deep. could this functionality be added to the selectable sidebar functions or could the mute buttons be one of the selectable items? |
…idebar pads in keyboard views (SynthstromAudible#255) (SynthstromAudible#901) * Add velocity on sidebar pads in isomorphic keyboard view * Change to velocity and mod in sidebar for isometric KB * Velocity and mod to column controls, add to in_key, Display::displayPopup(uint8_t), handle midi on instrument (noop for kit) * gitignore vim swap files * Start at instrument default velocity * Fix keyboard screen padPressHeld, fix clamping un/signed rollover, short press change, long press return to default * Chord mode working, switching column functions, more fixes * Add chord memory CMEM - bugged * Adding scale mode column control - working * Add dead pad state to keyboard, fix chord memory, comment out beat repeat * Change chord memory to save on short press to allow playing over chord * update for rgb * format * show current velocity/mod as white instead of default * Keyboard column control fixes - Fix missing check for dead pad presses - Adjustable SMOD pads to any scale - Change CMEM behavior to force clearing pads so you can play over it - Display::popup with long and short text for OLD/7SEG * Add keyboard column functions to community_features.md * Formatting * formatting --------- Co-authored-by: Rob McColl <rmccoll@seek-now.com> Co-authored-by: m-m-adams <mark.adams@queensu.ca>
Ready for review:
Inspired by the velocity drums keyboard and #255, this change adds various user-selectable functions to the mute and audition pad columns in the isometric and in-key keyboards. The functions include velocity (VEL), mod wheel (MOD), chord mode (CHRD), chord memory (CMEM), and scale mode (SMOD). There are commented out stubs for adding a beat repeat in the future. Hopefully it is simple to follow the pattern and add more functions over time.
For follow up: