I’m used to being able to click all over the place and change the states of windows (e.g. selecting the instrument, changing the loop marker) while leaving the focus in the pattern editor so that keypresses are still interacting with the pattern editor.
However - unlike all the other windows - the pattern matrix grabs the focus if you click on it. I want to be able to click on it (to navigate the song) and use clipboard commands on it (ctrl-c, ctrl-x, ctrl-v to manipulate patterns) without taking the focus away from the pattern editor. I find myself using ctrl-tab to get back to the pattern editor all the time where I barely ever used it before.
P.S. FEATURE REQUEST: ctrl-d when the pattern editor has the focus should copy/paste downward and move you down one pattern, like in an Excel doc. And it should create a new pattern if you’re at the bottom.
Sounds like an impossible request. Clipboard actions are bound to the area that has focus.
One of the reason why you can swiftly swap focus between the Matrix and the pattern editor.
There was quite a discussion during the Alpha testing about the part where the pattern editor did had focus locked and forgetting to swap to the middle mouse button started to became annoying for many testers. No problem with continueing this discussion in public, then there will be a clearer part in the average experience with this focus lock exception.
My preference: I would prefer it if mouseclicking did not move the focus, even if that means I can’t use the clipboard functions on the pattern matrix without ctrl-tabbing.
(Assuming I can still navigate the song by mouseclicking even if it doesn’t have the focus)
To me the usefulness of the pattern matrix is the top-down visualization of the song first, and the ability to manipulate patterns second. I will use the second a lot less often than the first, and not usually when I also want to be typing in the pattern editor.
Oh, you’re welcome. I get PAID for pointing out the bleedingly obvious. Mountains of money.
Seriously though, it is on topic. If I had to vote, my vote would be “make it configurable and be done with it, SINCE THAT TAKES LESS TIME THAN TO DISCUSS IT”. If that was not an option, I’d abstain. So there.
It is configurable! The issue is that this particular window overrides the already-present configurator, due to user feedback. I’m giving feedback in the opposite direction. I don’t like that it overrides the user preference configuration that I already set.
I don’t think it’s on the devs to incorporate a new configurable option because of every bit of user feedback, I am just casting my vote that I would like it another way. You know, like if this were a forum for discussion of a software beta.
“slippery slope” much? Because I think something would be better off configurabe, does not mean everything should be, even less so that it’s “on the devs”.
I don’t think it’s on the devs to weigh every bit of feedback to arrive at some magic solution that pleases everybody, and instead should just make stuff configurable and be done with it. I am just casting my vote that I would like it that way. You know, like if this were a forum for discussion of a software beta.
