|
|
|
04-22-2019, 02:41 PM
|
#1
|
Human being with feelings
Join Date: Apr 2016
Location: ASU`ogacihC
Posts: 3,921
|
v5.974+dev0422 - April 22 2019
v5.974+dev0422 - April 22 2019
+ Global hotkey override: allow defining overrides to force keys to be sent to main actions context, or to system processing, or to be ignored, etc
+ NINJAM: improve subsample accounting when importing clipsort.log
+ Project help: report correct time since last manual project save [t=219875]
+ ReaNINJAM: improve resampling issues at interval boundaries
+ Take FX: add actions to set take FX on/offline [t=220052]
+ Tooltips: improve multimonitor behavior
+ linux: improve keyboard handling with modal window open
# Notation editor: adjust positioning for voiced stemmed articulations
Full changelog / Latest pre-releases
|
|
|
04-22-2019, 03:25 PM
|
#2
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Originally Posted by Edgemeal
v5.974+dev0422 - April 22 2019
+ Global hotkey override: allow defining overrides to force keys to be sent to main actions context, or to system processing, or to be ignored, etc
|
I don't comment here a lot in the pre-release section, but I wanted to chime in here to say I think this current implementation is both terrible and horribly convoluted.
What advantage does this have vs just having a global overrides section?
"Keys bound to this will be ignored" ???? What is the point of this? I could go to the trouble of assigning hotkeys to this or just NOT assign them at all.
Not to mention that a key command should be tied to a specific action, not some random action that says "Keys tied to this will have default system/text field processing". How are you going to remember what is assigned to what this way?
A global override is just that. It globally overrides everything. This is not that and should not be labeled as such. Nor be a replacement. Because this is not in any way "global".
If you want to have destinations for certain hotkeys I'm all for it. But those destinations should be main arrange page, midi editor, plugin windows, etc. So shortcut for play/stop always goes to main regardless of what window is active etc.
This implementation with all of these different actions is just a mess. This is not an elegant solution whatsoever and certainly not "global".
Maybe I'm in the minority here but I don't see how in any way the below is a better solution. This really needs to be scrapped and rethought IMHO.
|
|
|
04-22-2019, 03:45 PM
|
#3
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,067
|
I must say, I'm also irritated. This concept doesn't look transparent to me.
|
|
|
04-22-2019, 04:15 PM
|
#4
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
Yeah it's not pretty, I agree. Hmm.
|
|
|
04-22-2019, 04:48 PM
|
#5
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
This would be my suggestion and again, I'm sure some people will disagree with me but honestly I think this is the best solution.
Right now in actions we have different sections for main, inline midi editor, midi editor, etc.
I think we should keep those categories listed separately - but only be LISTED separately, not treated separately.
I think key commands should not be separate for each section. I think key commands should work all the time REGARDLESS of what window is active (with the exception of active text fields but that's it.)
So the downside is you couldn't have 'S' do different things in the main arrange and in the midi editor window. However, I'm generally not going to assign 'S' to do different things in both those windows. It's too confusing.
Would this limit you in some ways? Of course. But it would solve a great many things including the above.
I'm also fine with the previous global overrides section as long as they don't override an active text field. Maybe others can chime in here so we can hone this down into something more manageable.
|
|
|
04-22-2019, 06:54 PM
|
#6
|
Human being with feelings
Join Date: Jul 2009
Posts: 7,595
|
yeah I don't like the look of that at all. having 8 of each just adds confusion. Any one of those could have multiple keys assigned, like the way passthrough to main works in the MIDI action list.
IMO it should be somewhere here:
Quote:
Originally Posted by Klangfarben
Right now in actions we have different sections for main, inline midi editor, midi editor, etc.
I think we should keep those categories listed separately - but only be LISTED separately, not treated separately.
|
one problem with doing this is that currently there are some Action IDs that are the same in different sections with different functions. Changing the action IDs could break a lot of things.
|
|
|
04-22-2019, 06:55 PM
|
#7
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,672
|
mark me as a respectful nay for klangfarben's suggestion. there are too many common actions across arrange screen and midi editor that would either need to be merged or duplicated. copy, paste, delete - S splits either midi note or item at edit cursor, etc. i don't want to turn to a completely different set of keys commands for common functionality. ctrl c ctrl v, no matter what screen you're in.
as for the issue itself -- we've worked around the window focus problem for years by assigning midi or osc to commands to actions instead of keys. these messages don't respect window focus. might there be a way to exploit this in order to accomplish global key overrides?
edit, epicsounds posted while i was composing my message. i agree, in my opinion, expected behavior would be for a global override checkbox in the window in his screenshot
|
|
|
04-22-2019, 06:59 PM
|
#8
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Thinking about it a little more I think most of this can be solved with the following:
- Keep the global overrides section as it was in previous dev releases
- Default behavior is global overrides NEVER override an active text field
- For the few exception cases (script windows that Reaper can't track, etc) have an action that toggles global overrides on/off
I think that would be an easier implementation than having one key command per action only. Especially for those who have already set up their workflow with a single key command triggering different actions in the main window, midi editor, etc. It's confusing to me to work that way but others may desire that workflow or rely on it.
Thoughts?
|
|
|
04-22-2019, 07:03 PM
|
#9
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Originally Posted by mccrabney
there are too many common actions across arrange screen and midi editor that would either need to be merged or duplicated. copy, paste, delete - S splits either midi note or item at edit cursor, etc. i don't want to turn to a completely different set of keys commands for common functionality. ctrl c ctrl v, no matter what screen you're in.
|
Sorry, I think I did a poor job of explaining myself above in post #6. Basically what I meant is that one key command could only be assigned to one action. So if 'S' is solo in the main window, 'S' is also solo in the midi editor. What you couldn't then do is assign 'S' to solo in the main window and 'S' to split in the midi editor. It would mean though streamlining the actions in each of the sections and removing duplicates which would take some work.
It would basically mean ALL key commands are global at all times, since only one key command can be used per action and thus would apply to all windows regardless of which is active. The different sections in the actions window would just be for organizational purposes. All the actions would just be one big section.
I also think my post #9 might be the easiest for the time being until people much more clever than myself can figure out a better way.
Last edited by Klangfarben; 04-22-2019 at 07:27 PM.
|
|
|
04-22-2019, 07:41 PM
|
#10
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,746
|
I think I have a good fix for the UI mess, stay tuned.
|
|
|
04-23-2019, 03:12 AM
|
#11
|
Human being with feelings
Join Date: Jul 2010
Location: Slovakia
Posts: 2,588
|
Quote:
Originally Posted by Edgemeal
# Notation editor: adjust positioning for voiced stemmed articulations]
|
With zooming, at one point, the position gets shifted by one space. Seems to be the case only for the low voice. It's correct when zoomed in.
Also notice in the top voice, how the articulation gets disaligned (this already was mentioned elsewhere I think).
Last edited by bFooz; 04-23-2019 at 04:20 AM.
|
|
|
04-23-2019, 04:03 AM
|
#12
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,067
|
Quote:
Originally Posted by Klangfarben
I think key commands should not be separate for each section. I think key commands should work all the time REGARDLESS of what window is active (with the exception of active text fields but that's it.)
|
I must say, that's one of the things I love and would like to keep.
Because of flexibility, I agree that it's always a bit more work to assign scripts on all different sections. But how about this?
quick and dirty (main alt recroding and MIDI event list editor are missing) and not pretty, but just for brainstorming:
EDIT: and maybe also this?
Last edited by _Stevie_; 04-23-2019 at 04:08 AM.
|
|
|
04-23-2019, 05:09 AM
|
#13
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
^^^^^ That method wouldn't quite work because for this you'd need all actions to be available across all contexts, which kinda defeats the purpose of having those contexts in the first place...
|
|
|
04-23-2019, 05:11 AM
|
#14
|
Human being with feelings
Join Date: Oct 2017
Location: Black Forest
Posts: 5,067
|
Good point, that's why we brainstorm. Keep it coming.
|
|
|
04-23-2019, 05:29 AM
|
#15
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,672
|
in the spirit of brainstorming --
Quote:
Originally Posted by mccrabney
as for the issue itself -- we've worked around the window focus problem for years by assigning midi or osc to commands to actions instead of keys. these messages don't respect window focus. might there be a way to exploit this in order to accomplish global key overrides?
|
i wanted to expand on this crackpot idea, but what if REAPER passed keypresses to itself as OSC? for instance, if a user hit the H key, the OS would see "H" but REAPER would also generate an osc message directed to itself titled ~ "Keypress H"
this way, a user could decide to assign the key itself - H, being dependent on the window focus - or the corresponding OSC message, which is window independent.
this is what i meant by exploiting the workaround that we've been using for years.
|
|
|
04-23-2019, 07:51 AM
|
#16
|
Human being with feelings
Join Date: Jul 2016
Location: Los Angeles, CA
Posts: 1,701
|
Quote:
Originally Posted by _Stevie_
quick and dirty (main alt recroding and MIDI event list editor are missing) and not pretty, but just for brainstorming:
|
I like this general idea. We would still most likely need a script to toggle all global overrides on/off. I'm not sure Reaper will be able to determine an active text field in all cases - different scripts, plugins etc.
|
|
|
04-23-2019, 08:58 AM
|
#17
|
Human being with feelings
Join Date: Aug 2015
Posts: 3,672
|
the text field bit of this FR seems like overkill to me. due to issues that Klangfarben raised, it might just end up making for more inconsistency. surely a control surface is better suited for any such urgent commands.
|
|
|
04-23-2019, 09:32 AM
|
#18
|
Human being with feelings
Join Date: Nov 2010
Posts: 2,436
|
Quote:
Originally Posted by Justin
I think I have a good fix for the UI mess, stay tuned.
|
Is is really so hard to know if FX processed keystroke or not and then use that keystroke to trigger REAPER stuff?
Just curious here as if why is this such a problem, code-wise?
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:41 AM.
|