introduce modifier buttons

[markusschloesser]

bring modifier buttons to action (control, alt, shift, option), so that we can use them to augment functionality.

I just did this (in shared_dev) and to test it, I changed the vpot_press for PLAY in function mode so that one can have (play, continue playing and play_selection). Unfortunately it doesn't work and I don't know if the problem is with the modifiers or with the changed play function. Would you mind taking a look?

[markusschloesser]

I seem to have a problem, to test if continue play works at all, I introduced continue play on vpot12 in function mode without any fancy modifier stuff. But even that doesn't work. FYI: the code is basically copied from the MackieControl classes (so old school, but tried and tested), and it works with the MackieControl, so wtf does it not here??

[markusschloesser]

at least SHIFT should work but does not, I implemented other things from MackieControl (see latest commit) which also do not work with shift. Must be somethings really stupid, but honestly I am lost after hours of trying to understand why it is not working

[markusschloesser]

Fuck, wrong script folder 🤪🤪🤪

[markusschloesser]

ok, it works, but not correctly. right now it's not momentarily, but permanently.

[markusschloesser]

I introduced continue play on vpot12 in function mode without any fancy modifier stuff. But even that doesn't work. FYI: the code is basically copied from the MackieControl classes (so old school, but tried and tested), and it works with the MackieControl, so wtf does it not here??

OK this does work now. But still the modifiers are permanent.

[BilldarBagdar]

I finally pulled down shared-dev and loaded it into Live. I wasn't able to fix anything with this issue.

What I did do was add some temporary LCD text in Function mode to indicate whether or not any modifier buttons are currently pressed, and it doesn't seem to work. I tried "both ways" if self.main_script().shift_is_pressed(): and if self.shift_is_pressed(): but it never seems to show "PRESSD" in the LCD for any modifier button. That seems logical doesn't it? If you hold down "Shift" and nothing else, that event should register in the script right? So the LCD should update between OFF and PRESSD, but it doesn't.

I'm getting tired tonight, so I'm not going any further. But I suspect correctly registering the "modifier" button presses will be a strong first step toward the larger goal of actually modifying the behavior of other buttons "correctly".

Maybe the CC values aren't exactly what would be expected? Dunno.

[BilldarBagdar]

Can you tell what the issue is from these log messages?

MackieC4) noteON<True> noteOFF<False> cc<False> received
MackieC4) note<13> velo<127> received
(MackieC4) noteON<False> noteOFF<True> cc<False> received
(MackieC4) note<13> velo<0> received
(MackieC4) button for note<13> is pressed<False> received
(MackieC4) Shift is pressed <False>
(MackieC4) noteON<True> noteOFF<False> cc<False> received
(MackieC4) note<13> velo<127> received
(MackieC4) noteON<False> noteOFF<True> cc<False> received
(MackieC4) note<13> velo<0> received
(MackieC4) button for note<13> is pressed<False> received
(MackieC4) Shift is pressed <False>
(MackieC4) noteON<True> noteOFF<False> cc<False> received
(MackieC4) note<14> velo<127> received
(MackieC4) noteON<False> noteOFF<True> cc<False> received
(MackieC4) note<14> velo<0> received
(MackieC4) button for note<14> is pressed<False> received
(MackieC4) Option is pressed <False>
MackieC4) noteON<True> noteOFF<False> cc<False> received
MackieC4) note<16> velo<127> received
(MackieC4) noteON<False> noteOFF<True> cc<False> received
(MackieC4) note<16> velo<0> received
(MackieC4) button for note<16> is pressed<False> received
(MackieC4) Alt is pressed <False>
(MackieC4) noteON<True> noteOFF<False> cc<False> received
(MackieC4) note<15> velo<127> received
(MackieC4) noteON<False> noteOFF<True> cc<False> received
(MackieC4) note<15> velo<0> received
(MackieC4) button for note<15> is pressed<False> received
(MackieC4) Control is pressed <False>

I'm not saying this represents the only issue. (yet) But this log message sequence illuminates a relatively "high level" problem in the logic for processing the 4 modifier buttons specifically, so it will cascade to all associated "downstream functions". These logs tell us exactly what happened, and I suspected this was happening before the logs proved it, but I still look at the code involved and it is difficult to "see" as a problem in the logic. Logic is hard. :) LOL, gotta love empirical evidence.

[BilldarBagdar]

Ok This much works

(MackieC4) Shift is pressed <True>
(MackieC4) Shift is pressed <False>
(MackieC4) Shift is pressed <True>
(MackieC4) Shift is pressed <False>
(MackieC4) Option is pressed <True>
(MackieC4) Option is pressed <False>
(MackieC4) Control is pressed <True>
(MackieC4) Control is pressed <False>
(MackieC4) Control is pressed <True>
(MackieC4) Control is pressed <False>
(MackieC4) Alt is pressed <True>
(MackieC4) Alt is pressed <False>
(MackieC4) Alt is pressed <True>
(MackieC4) Alt is pressed <False>

I don't know if the existing "modifier related" code is/was yours, but I don't think I disturbed it. I added and changed stuff, but some of what I added is duplicate if "both ways" hang around. (you'll see what I mean, I hope) I didn't check into any of the next level stuff you did to "modify" other events based on "pressed" or not. But the actual modifier button presses are registering correctly now it seems. Updates are in shared-dev.

[markusschloesser]

cool! will pull later and check. and yes, most of the modifier code was my doing.

[markusschloesser]

works fine! ☺ don't know if you saw the commit messages? I've implemented a couple of shift based extra functionality:

shift +

1. play > continue playing if stopped, otherwise stop (same as vpot12)
2. session/arr > focus view on window (if you happen to have 2 windows open, and it doesn't work anymore with 11.5b2 since now there's only ONE window)
3. clip/detail > focus_view
4. browser > focus browser

[BilldarBagdar]

Cool. I don't really use "continue". I mostly work in session view, and generally want all clips to start at the beginning when I "launch" using the "Song level" Play button. On the other hand, I use the "continue play" feature in Cubase a lot. (I use Cubase to "prepare" samples for further use in Live sessions) I will at least need to demo those "shifty" events. :)

BTW - If we want to implement "press and hold" behavior on the encoder knobs, we would just need to move that "receive midi" event method call outside (and also before :)) that "ignoring note offs" guard:

elif note in encoder_switch_ids:
    self.__encoder_controller.handle_pressed_v_pot(note, is_note_on_msg)

For example, we (you) already implemented "jump to default value" (if there is a default) behavior for the encoder presses. This code move would allow implementing "temporarily jump to default value". So, if you turn the knob to some non-default value, and then press and jump to the default value; if you press-and-hold long enough (1200 milliseconds?), then when you let go, it jumps back to the value it was before you jumped to default (instead of staying on the default after a (less than 1200 ms) press-and-release).

Also maybe just thought of a use for "control" (or whatever) in a similar vein. Implementing a kind of "snap-back to here" behavior for encoder turns. When you press-and-hold "control" and then turn some encoder, the script would remember the "existing value" when you start turning the encoder and "jump back" to that existing value when you release "control".

[markusschloesser]

works fine! ☺ don't know if you saw the commit messages? I've implemented a couple of shift based extra functionality:

shift +

1. play > continue playing if stopped, otherwise stop (same as vpot12)
2. session/arr > focus view on window (if you happen to have 2 windows open, and it doesn't work anymore with 11.5b2 since now there's only ONE window)
3. clip/detail > focus_view
4. browser > focus browser

I do not remember writing this at all 🤯😲😂 Currently thinking about functionality that would be useful with modifier buttons

[markusschloesser]

this was somehow lost/forgotten in the shared-dev branch, I now cherrypicked it into the current dev branch (2023_Dev_MS).

strangely, this works:

 elif self.ctrl_is_pressed():
                    self.song().play_selection()

whereas this does not:

elif encoder_index == encoder_26_index:
                if self.shift_is_pressed():
                    if not self.song().is_playing:
                        self.song().continue_playing()```

[markusschloesser]

ideas for modifier buttons:

• [x] BPM change by 0.1 (shift), 4 (CTRL)
• [ ] Zoom
• [ ] Scrub
• [ ] Loop Length
• [ ] Loop Start
• [ ] param min/max toggle (e.g. Sends, Devices)