v6.29+dev0520 - May 20 2021

[d. gauss]

Originally Posted by Edgemeal

v6.30+dev0520 - May 20 2021
[p=2445668]
+ Render: add options to normalize render to target peak or RMS

this is great. though while we're here, can't we have same that option for the "normalize" button in item properties? i.e. normalize item to -6? (been asking for awhile)

[X-Raym]

LUFS (Aka, loudness based) normalization at render would be far less straightforward than peaks or RMS, so IMHO it should be tackle in your mix and not at render.
Indeed, Loudness definitions can evolve (and it has, we are in EBU-128 v4.0 for broadcast ), so it is less universal than peaks and RMS.

And I also agree with the others that LUFS would be truly a great addition. Actually it is even more common and useful than RMS nowadays, isn't it?

RMS has still use even at render.
Integrated Loudness measurement requires sounds to be approx 3s long to be accurate, so below that for short samples like in sample libraries, RMS has still use.
RMS is also used a lot in plugin with "auto gain" feature because it is more CPU efficient, simpler to implement, and [delete]doesn't have any[/delete] has way lower lag (300ms per default here, but can be lower) contrary to LUFS momentary (which has a window of 500ms) or shortterm (3s if I remember well).

EDIT: lag here is statistical smoothing, based on window size, not CPU power related.

Originally Posted by andyp24

However, since some kind of brickwall True Peak limiter would be required for this, I think it's important that it's possible to choose the limiter you want to use.

This is another reason to do this in your mix rather than in the render window IMHO.



Anyway, peaks/RMS normalization are nice to have and still relevant And Loudness would be cool for sure.

[matt_t]

+ Tracks: prevent tiny (<0.1%) volume change on initial track fader click [t=191454]

Thanks!

[EvilDragon]

Originally Posted by schwa

You drew that checkbox in the pic? It's correct without the checkbox, the options are "Pool source data when track/item/razor edit [copies and/or splits] automation items".

Well, then it needs to be aligned better and spaced a bit tighter!

[ashcat_lt]

Originally Posted by Phazma

1) Wouldn't it be more efficient to create a 64bit float file on the 1st pass and on the 2nd pass just access that float file, calculate the max peak, adjust the gain and overwrite the temporary 64bit render with a render in the destination format?

More than efficient, it's kind of essential, at least as an option, but probably best as default. So many plugins and processes are random/non-deterministic that there's just no way of promising that the second render will peak the same as the first. In fact, in many many common cases, I think it's actually rather unlikely that the "normalized" second pass would meet the target peak value.

[Klangfarben]

Originally Posted by X-Raym

LUFS (Aka, loudness based) normalization at render would be far less straightforward than peaks or RMS, so IMHO it should be tackle in your mix and not at render.

And for those that have to stem out, we should individually mix each stem? There are a lot of reasons to tackle this in the render stage and not solely in the mix which by the way we can already do.

Originally Posted by X-Raym

Indeed, Loudness definitions can evolve (and it has, we are in EBU-128 v4.0 for broadcast ), so it is less universal than peaks and RMS.

I would give Justin and Schwa a lot of credit for keeping up with the evolution of things

Originally Posted by X-Raym

Integrated Loudness measurement requires sounds to be approx 3s long to be accurate, so below that for short samples like in sample libraries, RMS has still use.
RMS is also used a lot in plugin with "auto gain" feature because it is more CPU efficient, simpler to implement, and doesn't have any lag contrary to LUFS momentary (which has a window of 500ms) or shortterm (3s if I remember well).

Those of us looking for this feature aren't asking for no lag, instant rendering, etc. We realize this is at least one extra render pass and some very good suggestions have been made. It also doesn't affect anyone who doesn't need it or use it.

Originally Posted by X-Raym

This is another reason to do this in your mix rather than in the render window IMHO

Again, this is a matter of use cases. This isn't intended for just a "set and forget" or "auto mix" kind of thing. This is for the purposes of being more efficient and saving time. You obviously don't need it in your workflow. Others would benefit greatly.

[Edison]

Originally Posted by schwa

You drew that checkbox in the pic? It's correct without the checkbox, the options are "Pool source data when track/item/razor edit [copies and/or splits] automation items".

Hi Schwa,

Would it make sense this way?
Automation items: Pool source data to track/item/razor edit (Checkbox) copies (Checkbox) splits

I think from the text in [prefs_auto_help] it seems to me that it would make sense.


Thanks.

[Mercado_Negro]

Originally Posted by schwa

Yes, confirmed about the VST3 loading problems. In this build, we added a strictness check to the VST3 loading at the request of another developer. It turns out most plugins don't pass the check. We'll revert this change shortly.

It would be good to know if the problem is windows-only though, so if you have VST3 plugins that won't load on macOS please let us know here.

Tried most of my plug-ins including Voxengo, Fabfilter and iZotope and they all load fine.

macOS Big Sur 11.3 MacBook Pro M1

[Phazma]

Originally Posted by ashcat_lt

More than efficient, it's kind of essential, at least as an option, but probably best as default. So many plugins and processes are random/non-deterministic that there's just no way of promising that the second render will peak the same as the first. In fact, in many many common cases, I think it's actually rather unlikely that the "normalized" second pass would meet the target peak value.

Didn't think of it but this is an even more important reason than speed for solving normalized render in a different way. Actually if we can't predict the peak value reliably, normalizing in many cases is pointless. Other DAWs which have normalizing as render option also don't seem to do a full 2nd pass render. Whether they do something along the lines of what I suggested or something totally different I don't know but surely there has to be a more efficient and correct way of doing it.

For these reasons I also think it should be possible to set 2nd pass render and normalization separately. If both options are active it should first do 2 full renders where the second one overwrites the first and after the 2nd pass is completed the normalization (however it will be implemented) should take place in a third step.

[swiiscompos]

Originally Posted by Edgemeal

+ MIDI: fix duplicate CC values being sent at the start of linear/bezier curves

Is this bug somehow related to that? MIDI CC ramp values being sent to the FX chain while recording, but not recorded in the MIDI file and only when linear (and maybe bezier) curves are used: https://forum.cockos.com/showthread.php?t=252008

[cyoder]

Originally Posted by Edgemeal

v6.30+dev0520 - May 20 2021
+ Render: add options to normalize render to target peak or RMS

This is an incredible new feature! I would also be in favor of having LUFS as an option in addition to peak.

While the render dialogue is getting improvements, would it be possible for $item wildcards to work with the recently added option of rendering razor edits? Would be a huge time saver for me in sample editing, and IMO round it out to better match the abilities of the other render options.

[ferropop]

While rendering is being looked at, could Effect tails not being flushed, and bleeding into the render be addressed, just given how drastically this affects the whole purpose of using a DAW? <3

[ferropop]

Normalize Render to Peak RMS is so great. We've had useful actions to do these operations on Audio Items for a while, but these obviously don't apply to tracks with VSTi and effects, etc. This really opens up some possibilities.

[Klangfarben]

Originally Posted by ferropop

While rendering is being looked at, could Effect tails not being flushed, and bleeding into the render be addressed, just given how drastically this affects the whole purpose of using a DAW? <3

Big +1 for this. Will suffer the wrath of the off-topic gods for this as there is no conceivable reason the buffer should not be flushed before rendering.

[DANIELE]

Originally Posted by Edgemeal

v6.30+dev0520 - May 20 2021
* Includes feature branch: MIDI editor note reordering

What's this?

[ivansc]

Originally Posted by schwa

Ah that's my fault. Let's pretend it's 6.29+dev0520 shall we?

Disappointed.. I like even numbers.


P.S. @ DANIEL I am really hoping it means we can shuffle MIDI notes around to suit. Can`t think of any other way to interpret that.

[AZpercussion]

Originally Posted by Klangfarben

Those of us looking for this feature aren't asking for no lag, instant rendering, etc. We realize this is at least one extra render pass and some very good suggestions have been made. It also doesn't affect anyone who doesn't need it or use it.

Yes! Moreover, I guess, the 2nd pass will not take a lot of time, because after getting lufs value it needs only to adjust the level.
Also, maybe good solution to control peaks is able to choose fx chein for second pass.

[X-Raym]

Originally Posted by Klangfarben

. It also doesn't affect anyone who doesn't need it or use it.

Sure !
I'd like to highlight that I am not opposing against any reaper feature and everthing is welcome especially if it is desired by lot of people of the community
Just wanted to point that RMS is still valid even in render stage.

Edit:

Originally Posted by Klangfarben

Those of us looking for this feature aren't asking for no lag, instant rendering

About "lag", it isnt about performance issue or having an "instant render", but about data smoothing in statistical calculation of Loudness. It is related to Loudness window size, not CPU power. In resume, it just means that Loudness is not adapted for small sounds... and so RMS will still be valid in this case. :P And for longer sounds, Loudness will be perfect for sure.
(note: I edited my post to add precisions about this).

[X-Raym]

Originally Posted by Swcha

Note that if you enable normalizing to RMS, the "normalize to peak" setting then changes to "limit to peak." As an example, if you normalize to RMS -12dB and limit to peak -0.1dB, the file will be normalized to -12dB RMS *unless* that results in a peak over -0.1dB, in which case the file will be normalized to peak -0.1dB.

In this case, maybe "limit to peak", if it isn't limiting (as in "brickwall limiting"), should be called just "Normalize to Peak (Fallback)" or something like that?

[andyp24]

Originally Posted by X-Raym

LUFS (Aka, loudness based) normalization at render would be far less straightforward than peaks or RMS, so IMHO it should be tackle in your mix and not at render.

Very workflow dependent X-Raym...

If someone's working on contemporary music tracks of 4 mins length, sure. In my case, I may be working on a speech based broadcast programme that's an hour long. Of course, I will be setting the balance as I go through editing and mixing, aiming for a particular loudness target, but at the end of the programme when I come to render, it may still be a dB or two outside range (depending on a lot of factors). Then a producer may ask to re-edit a particular section, which can change the integrated LUFS value. With programmes that length, it's not feasible to listen through to the entire mix, raise things a dB or two to hopefully bring it into range, listen through to the entire thing again etc... The only practical way is to use a highly transparent brickwall limiter to adjust the final gain (while keeping true peaks compliant) and then render to see if you've hit the target. And then render again if it's 0.1dB outside range.

And then of course, I might have to deliver one version at -23LUFS for broadcast, and one at -16LUFS for a podcast version. It's not as simple as adding 7dB to the first one, since the limiter will then be working harder, pulling down more peaks and thus the overall level so the effective gain will be <7dB. Depending on the programme content and dynamics, it's not always easy to estimate how much "extra gain" you have to add to compensate for this.

Hence, this feature - to have Reaper do the heavy lifting for us so I can just press Render and go and make a cup of tea (or more likely, get on with some other work) knowing it will end up compliant - would be a great boost to workflow.

I have a feeling there's a script out there that might do this anyway - one of Heda's VIP scripts I think? But not sure if it's exactly what I'm describing.

Andy

[Phazma]

Originally Posted by X-Raym

Just wanted to point that RMS is still valid even in render stage.

You've made some good points about the validity of RMS. But I think nobody was even arguing against it. We are all happy with RMS being an option and want LUFS in addition to it (not instead of it). I personally just found it strange that LUFS wasn't there while RMS was, given that I think LUFS is applied in more situations (but that is subjective). andyp24 made a perfect example. In broadcast it is typical to request a specific LUFS level and if you can mix without having to worry too much about it or doing multiple renders and adjusting until the level is reached it saves a lot of time.

[X-Raym]

@andyp24, @Phazma
Thx for detailed workflow explanation, it makes sense !

[alphoc]

Woww multichannel render. So, is it possible multitake in one item render, in the future?

[mccrabney]

i'm still getting pooled AI when grabbing a slice from the middle of an existing AI.



note that the same maneuver doesn't result in a pooled AI if it isn't taken from the middle of an existing AI, for example taking a RE that includes either AI start or AI endpoint.

[_Stevie_]

Originally Posted by ferropop

While rendering is being looked at, could Effect tails not being flushed, and bleeding into the render be addressed, just given how drastically this affects the whole purpose of using a DAW? <3

THIS!!!

[Swi]

Originally Posted by ferropop

While rendering is being looked at, could Effect tails not being flushed, and bleeding into the render be addressed, just given how drastically this affects the whole purpose of using a DAW? <3

Big +1
Please work this out for us.

also my fabfilter plugs no longer load but it looks like you probably know there is a vst issue.

Thank you!
Make it great!

[lb0]

Originally Posted by ferropop

While rendering is being looked at, could Effect tails not being flushed, and bleeding into the render be addressed, just given how drastically this affects the whole purpose of using a DAW? <3

+1 - Yes this would be great!

[nofish]

Originally Posted by X-Raym

In resume, it just means that Loudness is not adapted for small sounds... and so RMS will still be valid in this case. :P And for longer sounds, Loudness will be perfect for sure.

FWIW SWS uses a 'trick' to also get LUFS integrated for short (less than 3 sec.) sounds, basically extending with silence which then gets gated away by the Loudness algorithm, so it'd be also possible to use with short sounds.

[Dafarkias]

+1 lufs

[BPBaker]

Originally Posted by nofish

FWIW SWS uses a 'trick' to also get LUFS integrated for short (less than 3 sec.) sounds, basically extending with silence which then gets gated away by the Loudness algorithm, so it'd be also possible to use with short sounds.

Interesting! I've often wondered about this, as I've found SWS's LUFS analysis of short sub 3 sec. items to be pretty good! (Until you get very very short items, e.g. micro-edits in a dialogue track.) Thanks for explaining.

(I realize this isn't the thread for this discussion, but it makes me wonder if there might be a way to make SWS LUFS analysis of short items "contextually intelligent" by somehow cross-referencing LUFS readings of adjacent items? Obviously this wouldn't be ideal for every situation, but would help dialogue editors and podcasters.)

[andyp24]

Perhaps this could be one of the uses for the "item container" feature that appeared in a recent dev build and then was removed again.

If all the items making up a segment of an interview etc could be "grouped" in a container that looks like a single item to SWS then it could do its Loudness Normalisation on the whole thing, instead of individual items.

[Valle]

OK, something happened ... Some of my VST3's didn't load. After re-scanning some came back, but not all of them.

Somebody else?

Edit: ALL of them Waves ... WHAT A SHOCKER!

Edit 2: Other hosts load OK.

[Phazma]

Originally Posted by Valle

Somebody else?. WHAT A SHOCKER!.

If you just briefly skim the thread you see many posts mentioning plugins from various manufactures not working. So no, it is not just you and the devs are well aware. They also explained that they were trying some security check which (as you see) many plugins don’t pass and they will revert it to how it was before.

[Valle]

Originally Posted by Phazma

If you just briefly skim the thread you see many posts mentioning plugins from various manufactures not working. So no, it is not just you and the devs are well aware. They also explained that they were trying some security check which (as you see) many plugins don’t pass and they will revert it to how it was before.

You are right, I should have skimmed. Sorry! (Most often when I have issue with VST, it's my system ... so I guess I wast just lazy.)

Thing is I went back to "stable" v6.29. But now they won't load even after cleaning and re-scanning.

For the time being I'm fine, though, because I don't use Waves anymore - in new projects, that is.

[BPBaker]

Originally Posted by andyp24

Perhaps this could be one of the uses for the "item container" feature that appeared in a recent dev build and then was removed again.

If all the items making up a segment of an interview etc could be "grouped" in a container that looks like a single item to SWS then it could do its Loudness Normalisation on the whole thing, instead of individual items.

I can definitely imagine this being helpful in later stages of dialogue mixing. My usual process for dialogue editing is to run SWS Loudness Normalization on raw files as I import them, then to periodically recalculating LUFS on more of a phrase by phrase basis as I edit. It would be nice to have the option of running the analysis on edited/grouped phrases that include micro-edits or room tone without suddenly adding 30db of gain. ;-)

[X-Raym]

Originally Posted by nofish

FWIW SWS uses a 'trick' to also get LUFS integrated for short (less than 3 sec.)

How that's the trick ? Simple but clever actually.

[chmaha]

Originally Posted by andyp24

+1 for LUFS target rendering.

Don't know if that's getting too complicated, but it'd be amazing if it's possible. Would save me a load of time rendering a programme, estimating the correction to make and re-rendering.... sometimes for a third time.

While you wait (and if you are on Linux), you could try my batch loudness normalization scripts:https://github.com/ElizabethHarmon/ebu-norm which give you loudness normalization, peak normalization or just analysis. All REAPER output formats are supported...

Adding my own +1 for built-in LUFS export support.