v6.45+dev0113 - January 13 2022

[sockmonkey72]

v6.45+dev0113 - January 13 2022

• * Includes feature branch: FX chain oversampling
• * Includes feature branch: render internals simplification/cleanup
• * Includes feature branch: user-defined action overhaul
• * Includes feature branch: media explorer toolbar
• * Includes feature branch: media item fixed lanes
• + Metadata: add ASWG dialogue projection level field
• + RS5k: fix incorrect resampling at end of sample (most obvious with r8brain free)
• + macOS: improve appearance of routing matrix in dark mode and default theme
• + macOS: run media/afx worker threads in realtime/audio workgroup if Time Critical priority is set
• # MIDI: main section action to reload MIDI track support files affects only selected tracks
• # macOS: accessibility arrow key fixes
  

This thread is for pre-release features discussion. Use the Feature Requests forum for other requests.

Changelog - Pre-Releases

Generated by X-Raym's REAPER ChangeLog to BBCode

[creal]

Thanks for all the updates.

I am just wondering if you plan to fix this bug about the brooken action "zoom to content" under certain circumstances: https://forum.cockos.com/showthread.php?t=261214

Have a nice weekend,

creal.

[tack]

[*]# MIDI: main section action to reload MIDI track support files affects only selected tracks

Brilliant. Works perfectly. Thanks!

[ovnis]

"# MIDI: main section action to reload MIDI track support files affects only selected tracks"

Someone can explain this, please?

[tack]

Originally Posted by ovnis

"# MIDI: main section action to reload MIDI track support files affects only selected tracks"

Someone can explain this, please?

If you change the global default ReaBank file, or other support files such as (presumably) CC/note names, this forces REAPER to notice the change and update the arrange view and MIDI editor (if applicable).

Reaticulate needs this in several cases, such as when changing articulation maps on a track. I needed some robust way to kick REAPER in the head to notice the changes, and schwa very kindly provided one.

[_Stevie_]

Originally Posted by tack

Brilliant. Works perfectly. Thanks!

Thanks devs!!!!

[ovnis]

Thx! Cool!

[dom64]

Originally Posted by creal

Thanks for all the updates.

I am just wondering if you plan to fix this bug about the brooken action "zoom to content" under certain circumstances: https://forum.cockos.com/showthread.php?t=261214

Have a nice weekend,

creal.

Please try and keep only to the items being discussed in the current dev build of this thread. Also be patient, the devs are doing what they can, when they can / all they can...

If you notice in the thread you've linked, there has already been acknowledgement and response after your last comment there.

All the best
Dom

[creal]

Originally Posted by dom64

Please try and keep only to the items being discussed in the current dev build of this thread. Also be patient, the devs are doing what they can, when they can / all they can...

If you notice in the thread you've linked, there has already been acknowledgement and response after your last comment there.

All the best
Dom

Okay, I understand.

All the best too.

[daxliniere]

Hey Justin, when O/S has been enabled on two or more consecutive plugins using the same O/S rate, can you confirm if there is logic that prevents superfluous downsample/upsample steps?

And how is it handled if the O/S rates are different? 2x -> 4x, 4x -> 2x.

[tapemelancholy]

Originally Posted by [*

* Includes feature branch: render internals simplification/cleanup

It will be nice to have normalize to peak (or true peak) by default instead of LUFS-I
Сonstantly have to switch that
Thanks!

[kindafishy]

Originally Posted by daxliniere

Hey Justin, when O/S has been enabled on two or more consecutive plugins using the same O/S rate, can you confirm if there is logic that prevents superfluous downsample/upsample steps?

And how is it handled if the O/S rates are different? 2x -> 4x, 4x -> 2x.

I would think that if you want this, you should be using fx chain OS, not individual plugin OS.

Further to that, I think that individual plugins should do up/down individually and it is not superfluous. By doing this, it avoids the need to stick ultrasonic filters in front of every non-linear plugin. I don't think I would bother to use the OS feature if it has the behaviour you describe.

[kindafishy]

Justin/Schwa

Sorry for the 're-post' but I am not sure of etiquette in this case. I didn't see response or reaction to this when I posted it in an earlier thread so I am dropping it here via copy/paste. Please let me know if this is against the rules or if you saw it and noted it, but just haven't commented on or addressed it yet.

______________________________________

In a 48 kHz project, when turning on OS either per fx or full chain, Nebula seems to still think that the sample rate is 48 kHz and this can be seen in the display where it shows 96 -> 48.

If I recall correctly, the problem is probably with Nebula in that it doesn't recognize SR changes after it has been loaded. Justin, Schwa, do you think there could be a solution to this that works both when adding the fx or when reloading a project where the plugin can be maybe re-initialized whenever there is a sample rate change or something - basically somehow 'tricking' the plugin into thinking it is being loaded for the first time and getting it to interpret the higher SR as the project rate?

[schwa]

Originally Posted by tapemelancholy

It will be nice to have normalize to peak (or true peak) by default instead of LUFS-I
Сonstantly have to switch that
Thanks!

The dialog remembers the last settings you selected, doesn't it?

[schwa]

Originally Posted by kindafishy

In a 48 kHz project, when turning on OS either per fx or full chain, Nebula seems to still think that the sample rate is 48 kHz and this can be seen in the display where it shows 96 -> 48.

If the plugin isn't responding correctly to the host notifying that the sample rate has changed, there may be nothing we can do short of unloading and reloading the plugin. What happens when you change the global sample rate in the audio settings?

[daxliniere]

Originally Posted by schwa

The dialog remembers the last settings you selected, doesn't it?

She/he might be talking about different projects, in which case the solution is to update their default project template.

[daxliniere]

Originally Posted by schwa

If the plugin isn't responding correctly to the host notifying that the sample rate has changed, there may be nothing we can do short of unloading and reloading the plugin. What happens when you change the global sample rate in the audio settings?

Also, are you sure you have the 96kHz files for that Nebula plugin installed?

[schwa]

Originally Posted by daxliniere

She/he might be talking about different projects, in which case the solution is to update their default project template.

The persistence is meant to be global.

[kindafishy]

Originally Posted by schwa

If the plugin isn't responding correctly to the host notifying that the sample rate has changed, there may be nothing we can do short of unloading and reloading the plugin. What happens when you change the global sample rate in the audio settings?

Below, 96000 Hz -> 48000 Hz indicates that Nebula (N4) loads a 96 kHz library but converts it to 48 kHz because it sees the DAW sample rate as 48 kHz, whereas 96000 Hz -> 96000 Hz indicates that it sees the sample rate as 96 kHz.


New 48 kHz project: Load N4 with preset - 96000 Hz -> 48000 Hz (as expected)
Change FX instance oversampling to 2x - 96000 Hz -> 48000 Hz (N4 does not immediately react)
Closed and reopened the project - 96000 Hz -> 48000 Hz (N4 loads as 48 kHz - confirmed 2x is still set)

Deleted project (starting next test clean)

New 48 kHz project: Load N4 with preset - 96000 Hz -> 48000 Hz (as expected)
Change project setting to 96 kHz - 96000 Hz -> 48000 Hz (N4 does not immediately react)
Closed and reopened the project - 96000 Hz -> 96000 Hz (N4 loads as 96 kHz *** good!)

Deleted project (starting next test clean)

New 48 kHz project: Load N4 with preset - 96000 Hz -> 48000 Hz (as expected)
Change Chain oversampling to 2x - 96000 Hz -> 48000 Hz (N4 does not immediately react)
Closed and reopened the project - 96000 Hz -> 48000 Hz (N4 loads as 48 kHz - confirmed 2x is still set)


Here is some other interesting behaviour that I stumbled upon. Using that last project, I had chain OS set to 2x and then I removed N4. No plugins on this track at this point. I loaded N4 again and noticed that the display says 96000 Hz -> 96000 Hz. I am in a 48 kHz project. I checked, and the Chain oversampling is still set to 2x, so the setting is remembered for this track even though there were no plugins on the track for a moment. The interesting part to this though, is that N4 sees the DAW sample rate as 96 kHz. Also very interesting is that when closing and re-opening the project, it is still reporting 96000 Hz -> 96000 Hz.

Hopefully you see some ideas and potentials in these test results. If unloading/reloading the plugin would lead to a correct operating state, I think that would be a fair compromise (certainly preferable to it not working at all).

[kindafishy]

Originally Posted by daxliniere

Also, are you sure you have the 96kHz files for that Nebula plugin installed?

Of course, but it was worth checking to make sure the tests are valid so thanks for asking.

[daxliniere]

Originally Posted by kindafishy

Here is some other interesting behaviour that I stumbled upon...

Might be time to ask Giancarlo @ Acustica.

[schwa]

Originally Posted by kindafishy

If unloading/reloading the plugin would lead to a correct operating state, I think that would be a fair compromise (certainly preferable to it not working at all).

I don't think REAPER should unload it and reload it, as that would be highly disruptive. What I'd suggest that you toggle the plugin offline and online when changing sample rates (ctrl+alt+B with the plugin focused).

[kindafishy]

Originally Posted by daxliniere

Might be time to ask Giancarlo @ Acustica.

Ha! No thanks. I have been down the AA support rabbit hole too many times. I know better.

I have no expectations here or misconceptions that this is somehow REAPER's problem or responsibility, but it is worth having the conversation in case it can be made to work in some way.

In the end, if it works, it works, if it doesn't it doesn't, but I am not subjecting myself to conversing with AA support staff (the PR guy on GS excluded, he is awesome).

[kindafishy]

Originally Posted by schwa

I don't think REAPER should unload it and reload it, as that would be highly disruptive. What I'd suggest that you toggle the plugin offline and online when changing sample rates (ctrl+alt+B with the plugin focused).

With fx chain OS, setting it offline and online again had no effect. Setting it offline, closing the project, reopening the project and then setting it online loaded the 96 kHz library at 96 kHz.

With individual fx OS, no combination will bring it online at 96 kHz.

I don't at all expect you guys to knock yourselves out or jump through hoops for this, but if you can come up with something, that would be awesome. I think it is quite clearly an issue with N4.

[schwa]

Oh, there's no question it's specific to this plugin I don't think there's anything we'll be changing on the REAPER side for this issue.

If offlining and onlining doesn't fix the sample rate, and there is nothing else the plugin is communicating with (some process outside of REAPER, or other instances of the plugin in the project), that means the sample rate is stored by the plugin as part of its overall state and there's nothing REAPER could possibly do about it anyway.

[kindafishy]

Originally Posted by schwa

Oh, there's no question it's specific to this plugin I don't think there's anything we'll be changing on the REAPER side for this issue.

If offlining and onlining doesn't fix the sample rate, and there is nothing else the plugin is communicating with (some process outside of REAPER, or other instances of the plugin in the project), that means the sample rate is stored by the plugin as part of its overall state and there's nothing REAPER could possibly do about it anyway.

Hey, thanks for discussing it. It's appreciated very much. Maybe a future N4 plugin will work better. Until then, it looks like I am mixing at 96 kHz (which I am already doing anyway, so no harm). What really kind of sucks is that I can't take advantage of a DAW feature that I have wanted for a long time because of some plugins that I enjoy using. I am aware there are other workarounds (like metaplugin), so I'll probably find a workflow that works for me.

Thanks schwa!

[Mercado_Negro]

Originally Posted by kindafishy

Hey, thanks for discussing it. It's appreciated very much. Maybe a future N4 plugin will work better. Until then, it looks like I am mixing at 96 kHz (which I am already doing anyway, so no harm). What really kind of sucks is that I can't take advantage of a DAW feature that I have wanted for a long time because of some plugins that I enjoy using. I am aware there are other workarounds (like metaplugin), so I'll probably find a workflow that works for me.

Thanks schwa!

Maybe you can only oversample everything else in the chain but N4. I know it's more work but it does the job.

[daxliniere]

Originally Posted by Mercado_Negro

Maybe you can only oversample everything else in the chain but N4. I know it's more work but it does the job.

https://forum.cockos.com/showpost.ph...56&postcount=2

"One feature I would love to see is the ability to set a single plugin to 'never oversample'..."

[kindafishy]

Originally Posted by Mercado_Negro

Maybe you can only oversample everything else in the chain but N4. I know it's more work but it does the job.

Indeed, that's what I am thinking, with the addition of running N4 in metaplugin because I don't run any AA at 48 kHz. I have deleted all non 96 kHz programs and vectors from my installation (where possible).

I'm ok working at 96 though. I've been doing it for a couple years now.

[Mercado_Negro]

Originally Posted by daxliniere

https://forum.cockos.com/showpost.ph...56&postcount=2

"One feature I would love to see is the ability to set a single plugin to 'never oversample'..."

I'd rather see an option to "always oversample this plug-in" and enable it for those I'd always want tor run in that way. This option would appear in the FX browser menu when right-clicking on the plug-ins.

[Mercado_Negro]

I think the oversampling shouldn't be tied to the project resample mode. Why not use r8brain for it and that's it? It's obvious that this is the best algorithm in REAPER at the moment.

[rafa1981]

Not the best for latency though.

[Mercado_Negro]

Originally Posted by rafa1981

Not the best for latency though.

If you're oversampling a plug-in it means you know you have to deal with latency so I don't think that's valid point.

[Funkybot]

Originally Posted by Mercado_Negro

I'd rather see an option to "always oversample this plug-in" and enable it for those I'd always want tor run in that way. This option would appear in the FX browser menu when right-clicking on the plug-ins.

I'd thought about this last night. There's a small handful of plugins I'd probably enable this on if I had the option.

[daxliniere]

Originally Posted by Mercado_Negro

Why not use r8brain for it and that's it? It's obvious that this is the best algorithm in REAPER at the moment.

I'll send you something I did. I actually prefer the sound of 768pt sinc.

[Ben Zero]

Originally Posted by daxliniere

I actually prefer the sound of 768pt sinc.

Exactly my experience so far too!

[tapemelancholy]

Originally Posted by schwa

The dialog remembers the last settings you selected, doesn't it?

Yeah but it resets from time to time for some reason (I haven't figured out what it is yet)

[gapalil001]

Originally Posted by kindafishy

Below, 96000 Hz -> 48000 Hz indicates that Nebula (N4) loads a 96 kHz library but converts it to 48 kHz because it sees the DAW sample rate as 48 kHz, whereas 96000 Hz -> 96000 Hz indicates that it sees the sample rate as 96 kHz.


New 48 kHz project: Load N4 with preset - 96000 Hz -> 48000 Hz (as expected)
Change FX instance oversampling to 2x - 96000 Hz -> 48000 Hz (N4 does not immediately react)
Closed and reopened the project - 96000 Hz -> 48000 Hz (N4 loads as 48 kHz - confirmed 2x is still set)

Deleted project (starting next test clean)

New 48 kHz project: Load N4 with preset - 96000 Hz -> 48000 Hz (as expected)
Change project setting to 96 kHz - 96000 Hz -> 48000 Hz (N4 does not immediately react)
Closed and reopened the project - 96000 Hz -> 96000 Hz (N4 loads as 96 kHz *** good!)

Deleted project (starting next test clean)

New 48 kHz project: Load N4 with preset - 96000 Hz -> 48000 Hz (as expected)
Change Chain oversampling to 2x - 96000 Hz -> 48000 Hz (N4 does not immediately react)
Closed and reopened the project - 96000 Hz -> 48000 Hz (N4 loads as 48 kHz - confirmed 2x is still set)


Here is some other interesting behaviour that I stumbled upon. Using that last project, I had chain OS set to 2x and then I removed N4. No plugins on this track at this point. I loaded N4 again and noticed that the display says 96000 Hz -> 96000 Hz. I am in a 48 kHz project. I checked, and the Chain oversampling is still set to 2x, so the setting is remembered for this track even though there were no plugins on the track for a moment. The interesting part to this though, is that N4 sees the DAW sample rate as 96 kHz. Also very interesting is that when closing and re-opening the project, it is still reporting 96000 Hz -> 96000 Hz.

Hopefully you see some ideas and potentials in these test results. If unloading/reloading the plugin would lead to a correct operating state, I think that would be a fair compromise (certainly preferable to it not working at all).

Nebula 4 doesn't like sample rate changing "on the fly". you can be sure about it if you'll test it in Plugin Doctor with dynamic sample rate change. some results may shock you, particularly frequency spectrum after changing sample rate. the only one way to oversample N4 properly - add instance to already oversampled chain.
Nebula 4 is problematic plugin and needs some improvements from AA side. but, according to how do they hate it, i'm not sure that it will happens

[kindafishy]

Originally Posted by gapalil001

Nebula 4 doesn't like sample rate changing "on the fly". you can be sure about it if you'll test it in Plugin Doctor with dynamic sample rate change. some results may shock you, particularly frequency spectrum after changing sample rate. the only one way to oversample N4 properly - add instance to already oversampled chain.
Nebula 4 is problematic plugin and needs some improvements from AA side. but, according to how do they hate it, i'm not sure that it will happens

That all mirrors my thoughts and experiences.

I just submitted a ticket to Acustica about N4 to see if they are going to fix the buggy sample rate switch handling. No doubt they will tell me it is a feature and they have no ETA. I really hope that they don't abandon N4 as some users think will happen. It is still in my top 3 most expensive plugin purchases ever and I have used it on every project for the last... well... forever.

[Justin]

Originally Posted by daxliniere

Hey Justin, when O/S has been enabled on two or more consecutive plugins using the same O/S rate, can you confirm if there is logic that prevents superfluous downsample/upsample steps?

And how is it handled if the O/S rates are different? 2x -> 4x, 4x -> 2x.

This would be easy for you to test to see, but: Per-instance oversamples/downsamples per-instance, per-chain oversamples/downsamples the chain.