search

jcsteh / osara

OSARA: Open Source Accessibility for the REAPER Application
GNU General Public License v2.0
127 stars 46 forks source link

Gain Reduction meter for Dynamic Plugins #617

Closed Nils31011992 closed 2 years ago

Nils31011992 commented 2 years ago

It would be great to have a Kind of Gainreduction Meter for Compressors and other dynamic tools, especially for less experienced users or people who can not see the Meters in Plugins.

jcsteh commented 2 years ago

I don't see how this would be possible for OSARA. In order for OSARA to do that, the plugin would need to expose that information programmatically. The only way to do that as far as I know is via a parameter. And if it exposed a parameter, you'd be able to see it in OSARA's Parameters dialog.

Nils31011992 commented 2 years ago

you can get a gain reduction value in db from the api, so it would work at least for vst3 plugins I think

RDMurray commented 2 years ago

Where did you find this in the API? I couldn't find anything about gain reduction.

A way it could be done is by inserting a custom jsfx before and after the effect to be measured, which could expose a parameter that could be read by OSARA, similar to how the peak watcher works.

I do think something like this would be useful. Did you have an idea for how the UX would work for this?

Nils31011992 commented 2 years ago

Here,

https://forums.cockos.com/showthread.php?t=232577

Von meinem iPhone gesendet

Am 14.12.2021 um 12:58 schrieb RDMurray @.***>:

 Where did you find this in the API? I couldn't find anything about gain reduction.

A way it could be done is by inserting a custom jsfx before and after the effect to be measured, which could expose a parameter that could be read by OSARA, similar to how the peak watcher works.

I do think something like this would be useful. Did you have an idea for how the UX would work for this?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

RDMurray commented 2 years ago

This is only documented in the changelog:

I wonder how widely supported that API is?

We could make an action to report the current gain reduction for the focused effect using that API fairly easily. The problem as always with new actions is where to put them on the keymap?

jcsteh commented 2 years ago

Ah, I knew about that API, but I incorrectly thought it was only for Cockos effects which I believe already expose gain reduction in the GUI in an accessible way. It we indeed be interesting to know how many other effects support that.

ScottChesworth commented 2 years ago

The forum thread that Nils linked to indicates it's supported by Waves VST3. Beyond that, I don't know. How much work would be involved in whipping up that action to start testing in situ Robbie? I think that's probably the only way to find out how useful it is. Doing the gruntwork first isn't something I'd usually consider, but given how useful gain reduction on demand would be, maybe this is an exception.

jcsteh commented 2 years ago

We could use the key hook to hard-code a shortcut which only works in the FX chain dialog, since this can only work for a focused effect anyway. The only problem with that is that it would be Windows only.

ScottChesworth commented 2 years ago

The only problem with that is that it would be Windows only.

Nils is on Mac. Also, I know of a bunch of other Mac users who would be extremely sad to miss out on this if it happens. Originally I wondered about getting it into Peak Watcher, but I don't think that's an option until we know how wide support is.

jcsteh commented 2 years ago

The problem with an action is that it won't do anything unless an FX chain dialog is open, since otherwise, an effect can't be focused (so we don't know which one the user wants to query). The same problem applies if we tried to do this in Peak Watcher. How does it know which effect to query? What if there are multiple effects on the track with gain reduction meters?

jcsteh commented 2 years ago

But FWIW, implementing this as an action above caveats notwithstanding) should be a 5 minute job or less.

ScottChesworth commented 2 years ago

Uh oh, yeah, that's a sticky wicket. Any mileage in doing this as a reascript that we could bundle with OSARA to get Mac support?

jcsteh commented 2 years ago

ReaScript wouldn't be any different to an OSARA action. It's probably just easiest to implement it as an OSARA action. I was just trying to avoid adding something else to the main key map which can only actually be used in the FX chain dialog, since it's a wasted key then at all other times. But I guess there just isn't a way to do that cross-platform.

RDMurray commented 2 years ago

It could be included in the Mac keymap, and be hard coded for the FX window on windows. I seem to remember that there are keys that can only be assigned on Mac anyway?

ScottChesworth commented 2 years ago

It could be included in the Mac keymap, and be hard coded for the FX window on windows.

That sounds like a good middle ground. Mac folk aren't as pushed for space on their key map because they have tons of spare space with Control as a modifier, so the extra keystroke not being context sensitive won't be a biggy for them IMO.

jcsteh commented 2 years ago

In that case, I'd suggest starting with the action unbound, letting people take it for a spin (binding as they wish) and evaluating its usefulness. If it does turn out to be super useful, we can do the extra work to bind it in the FX chain, since that is going to be a bit trickier and uglier than the action.

ScottChesworth commented 2 years ago

Makes sense yep. Now the million dollar question: who wants to implement it? :)

RDMurray commented 2 years ago

I'm experimenting with it, but reacomp doesn't seem to support this API. Apparently it is implemented by waves and brainworx compressors, and presumably presonus. I don't have any of those on this machine.

ScottChesworth commented 2 years ago

I have compressors from both here, happy to have you test stuff using my machine via NVDA remote if that would help?

RDMurray commented 2 years ago

Thanks @ScottChesworth but I have since found out that reacomp is indeed supposed to support this API, so I must be doing something wrong.

RDMurray commented 2 years ago

I found the problem, it was a typo. It does work with reacomp.

I have a few more questions about how this should work:

Nils31011992 commented 2 years ago

Ok, How would it work in general? It would be good to have the gainreduction for every plugin.

Von meinem iPhone gesendet

Am 14.12.2021 um 20:23 schrieb RDMurray @.***>:

 I found the problem, it was a typo. It does work with reacomp.

I have a few more questions about how this should work:

Should we cache the focused effect so that it continues to work when the fx window is closed? If there isn't an effect focused, should we report gain reduction for the first supported effect on the last touched track? Ditto for the current item? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

ScottChesworth commented 2 years ago 
* Should we cache the focused effect so that it continues to work when the fx window is closed?

I'd say yes, given that we're not using the key hook to restrict it to the FX window now.

* If there isn't an effect focused, should we report gain reduction for the first supported effect on the last touched track?

Can you report the name of the plug-in the reading is from after the dynamic content? EG, "-3 ReaComp"? Reporting the first supported effect on last touched track is excellent in terms of convenience, but I think it needs to be clear which plug-in is being reported if the user hasn't chosen that by manually focusing the effect.

* Ditto for the current item?

Yeah, I can't see any reason to treat take-based fx differently.

Thanks man, super excited to try this out when you're ready.

ScottChesworth commented 2 years ago

It would be good to have the gainreduction for every plugin.

Steady on soldier, we don't even know how widely supported this information is yet. Let's do some testing and go from there.

RDMurray commented 2 years ago 
* Should we cache the focused effect so that it continues to work when the fx window is closed?

I'd say yes, given that we're not using the key hook to restrict it to the FX window now. It will be a bit more difficult to support caching current FX and last touched track/take at the same time. Not impossible, but it would mean adding code related to this action to other unrelated functions.

* If there isn't an effect focused, should we report gain reduction for the first supported effect on the last touched track?

Can you report the name of the plug-in the reading is from after the dynamic content? EG, "-3 ReaComp"? Reporting the first supported effect on last touched track is excellent in terms of convenience, but I think it needs to be clear which plug-in is being reported if the user hasn't chosen that by manually focusing the effect.

Yes, good idea.

jcsteh commented 2 years ago

Why would caching/last touched require code in other functions? If OSARA's focus or the cached track/take aren't equal, fall back to last touched track/take depending on focus.

The first effect as a fallback seems really arbitrary to me. Why not the last? Why do we think the first will always be the most useful? I get the "better than nothing argument", but I'm not sure if that's true here, since it will only serve in very specific circumstances and users might not understand why a given effect is being chosen even with the name reported. In addition, it adds complexity, which is fine if the benefit is clear, but I'm not yet convinced of that.

jcsteh commented 2 years ago

More clarification on my caching comment:

  1. Consider the cached track or take.
  2. If OSARA's focus isn't track and we have a cached track, it's invalid. Ditto for take.
  3. Otherwise, if it's a track and it's not equal to the last touched track, the cache is invalid. Ditto for take.

All of that said, how are you caching the last focused effect anyway? I don't see how that can be done in a cross-platform way.

ScottChesworth commented 2 years ago

The first effect as a fallback seems really arbitrary to me. Why not the last? Why do we think the first will always be the most useful?

Fair questions, turns out I don't have strong answers to any of those lol. Let's go with users focusing the effect that they want gain reduction for. That's gonna be the clearest UX.

jcsteh commented 2 years ago

On Mac, we can't detect when the focused effect changes, nor can we detect when the FX chain dialog closes.

ScottChesworth commented 2 years ago

Fiddlesticks! How hard would it be to build a window populated with fx instantiated on the currently selected track or item on Mac? I'm just spitballing here.

ScottChesworth commented 2 years ago

Sorry, should've been clearer. OSARA action runs, displays a list of FX that are instantiated on the currently selected track or item, user chooses which of those they want gain reduction feedback for.

Lo-lo78 commented 2 years ago

Yes, we could think of a Peak Watcher type window ...

I really like the idea; since James loves to make gui in C ++!

😅

RDMurray commented 2 years ago

Sorry, I haven't checked this thread for a few hours.
To cache the last focused FX, I was just planning to store the outputs from GetFocusedFX in static variables.

Doesn't GetFocusedFX work on Mac?

The first effect as a fallback seems really arbitrary to me. Why not the last? Why do we think the first will always be the most useful?

The idea behind the option of selecting the first supported FX on the track/take was to speed up the case where you have one compressor on a track and want to check the gain reduction quickly.

If it is sometimes the last focused effect, and at other times changes based on focus it could be unclear to the user exactly when it will change. I think that always using the last focused FX would be the most consistent UX.

It would be clearer if the effect is always selected explicitly, and would allow for things like checking a compressor on a folder while adjusting levels of individual tracks

jcsteh commented 2 years ago

To cache the last focused FX, I was just planning to store the outputs from GetFocusedFX in static variables.

Sure... but when? I guess we could do this only in the action itself, but that would require you to run the action while the FX chain was open in order for it to cache the last effect. Is that intuitive, though?

Doesn't GetFocusedFX work on Mac?

It does. I assumed you meant cache the last focused effect regardless of whether the action was run. That would require detecting when the focused FX changed or when the FX chain closed, which can't be done on Mac.

RDMurray commented 2 years ago

ah yes, I didn't think of that. It does require running the action when the effect is focused. Like you say, there is no cross platform way to detect the last focused effect otherwise. I still think it is useful to be able to read the gain reduction when the FX window is closed.

RDMurray commented 2 years ago

Would this be okay if it is clearly documented? Having subtly different behaviour on Windows and Mac would probably be more unintuitive.

jcsteh commented 2 years ago

I think it's useful too, but I worry users will be confused by the current behaviour. For example, they might do the following:

  1. Open an FX chain and focus an affect.
  2. Report the gain reduction.
  3. Close the FX chain.
  4. Open a different FX chain and focus an effect.
  5. Close the FX chain.
  6. Report the gain reduction.

What they'll get at this point is the gain reduction for 1), not 4) as they might expect.

jcsteh commented 2 years ago

We can fix that on Windows, but not on Mac. Did I mention how much I hate having to support Mac?

ScottChesworth commented 2 years ago

Did I mention how much I hate having to support Mac?

Oh no, I've already wrapped up a Big Mac with extra cheese and posted it to Australia as a Christmas prezzie. Thought it was your favourite. Bit awkward.

mattymc2 commented 2 years ago

I’ll take it

Sent from my iPhone

On 15 Dec 2021, at 2:37 pm, ScottChesworth @.***> wrote:

 Did I mention how much I hate having to support Mac?

Oh no, I've already wrapped up a Big Mac with extra cheese and posted it to Australia as a Christmas prezzie. Thought it was your favourite. Bit awkward.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

ScottChesworth commented 2 years ago

I've sent you a flat white (and a note explaining that it's just a coffee, not a gig review)