v6.29+dev0603 - June 3 2021

[vitalker]

v6.29+dev0603 - June 3 2021

• * Includes feature branch: render normalization
• * Includes feature branch: MIDI editor note reordering
• * Includes feature branch: media item lanes
• * Includes feature branch: EEL2 x86_64/SSE
• * Includes feature branch: VST3 bridging
• + Actions: add action to calculate loudness of selected tracks within time selection via dry run render
• + ReaScript: support getting/setting render normalization mode and target
• + Render: add preference to calculate true peak on render when not normalizing to it
• + VST3: add IPlugInterfaceSupport, for plugins to request compatibility features
• + VST3: add support for IMidiLearn interface
• + VST3: avoid threading conflicts when processing expression and keyswitch information
• + VST3: internal threading changes to MIDI controller and program change handling
• # Batch converter: fix button positioning when window is resized
• # Convert: fix normalization for source files that do not have an embedded source start time [p=2450739]
• # MIDI editor: fix keyboard drawing glitches around top of view [p=2450683]
• # MIDI note ordering: fix ordering issue after undo [p=2449996]
• # MIDI note ordering: give more visual feedback about selected note [p=2450000]
• # Rendering: fix denormal issues with silence [p=2450456]

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

[Meo-Ada Mespotine]

Originally Posted by vitalker

[*]+ ReaScript: support getting/setting render normalization mode and target

Yeah! Thank you!

[Triode]

With all these normalisation and true peak functions is there a way of bouncing a mix directly from a 48k session and converting to 44.1k while ensuring no inter sample overs?

[ovnis]

"# MIDI editor: fix keyboard drawing glitches around top of view [p=2450683]"
Thx. It works!

[Phazma]

Originally Posted by vitalker

+ Actions: add action to calculate loudness of selected tracks within time selection via dry run render
+ ReaScript: support getting/setting render normalization mode and target

Thanks for these! I guess now we really have all LUFS calculation actions we could possibly need. Maybe (for the sake of completion) calculating loudness on master with/without time selection could be convenient to have as actions too..? But It's not really that important as it can easily be done with a dry-run render (or as a script).

Originally Posted by vitalker

+ Render: add preference to calculate true peak on render when not normalizing to it

Nice! Maybe we can also have a preference to hide RMS-I when not normalizing to it? Less unnecessary numbers mean less visual clutter and I believe in the LUFS-era most people don't need to see RMS-I anyway?

Originally Posted by vitalker

# Batch converter: fix button positioning when window is resized
# Convert: fix normalization for source files that do not have an embedded source start time [p=2450739]
# MIDI editor: fix keyboard drawing glitches around top of view [p=2450683]

Thanks! I can confirm that all three bugs are fixed now.

[nofish]

Originally Posted by Phazma

Maybe (for the sake of completion) calculating loudness on master with/without time selection could be convenient to have as actions too..? But It's not really that important as it can easily be done with a dry-run render (or as a script).

Agreed it's actually not that important, but as a sidenote, I intuitively expected that it already works with the 'calculate loudness of selected tracks [within time selection] via dry run render' action when having only the master track selected (I mean by the wording of it it should, right?) but it doesn't.

[Phazma]

Originally Posted by nofish

Agreed it's actually not that important, but as a sidenote, I intuitively expected that it already works with the 'calculate loudness of selected tracks [within time selection] via dry run render' action when having only the master track selected (I mean by the wording of it it should, right?) but it doesn't.

Funny, I actually tried that too and after it didn't work I made the suggestion here. Perhaps separate actions would make it easier to identify (and not dependant on track selection) but just expanding the functionality of the already existing actions would be perfectly fine too.

[schwa]

Originally Posted by Phazma

Nice! Maybe we can also have a preference to hide RMS-I when not normalizing to it? Less unnecessary numbers mean less visual clutter and I believe in the LUFS-era most people don't need to see RMS-I anyway?

We added an option to not calculate true peak if not normalizing to it because that's the only calculation that has any meaningful CPU cost. The other calculations are much cheaper.

[Phazma]

Originally Posted by schwa

We added an option to not calculate true peak if not normalizing to it because that's the only calculation that has any meaningful CPU cost. The other calculations are much cheaper.

Thanks for the info, was a very good idea indeed to save some CPU that way.
My suggestion was not about the CPU cost but more about reducing visually distracting information when it is not needed. But I can understand it, if this is not enough of a reason to fill the precious preferences space with an extra option.

[Funkybot]

Hi devs, I'm still getting lost note orders when gluing items with BFD3. Here are my steps:

1. MIDI Editor open and docked (one per project). 2. Insert an empty item. 3. Create a simple 4 note closed hat pattern. 4. Rearrange the drum notes to sort the hat articulations together. 5. Duplicate items. 6. Glue.






Undo restores the prior note order.

[citizenkeith]

Is there a chance that some of these normalization additions can be added to Consolidate/Export?

[Justin]

Originally Posted by Funkybot

Hi devs, I'm still getting lost note orders when gluing items with BFD3. Here are my steps:

1. MIDI Editor open and docked (one per project). 2. Insert an empty item. 3. Create a simple 4 note closed hat pattern. 4. Rearrange the drum notes to sort the hat articulations together. 5. Duplicate items. 6. Glue.






Undo restores the prior note order.

Ah yes, you can get the custom note ordering back by going to view->show/hide note rows->custom note order. Fixing that change so that it preserves when glueing.

[chmaha]

Originally Posted by Phazma

Maybe we can also have a preference to hide RMS-I when not normalizing to it? Less unnecessary numbers mean less visual clutter and I believe in the LUFS-era most people don't need to see RMS-I anyway?

+1...RMS-I result should probably not be shown by default in the age of LUFS. Also please consider adding LUFS-M and LUFS-S as options for render targets.

[Dafarkias]

Originally Posted by vitalker

[*]+ ReaScript: support getting/setting render normalization mode and target

Could we add an option in the API to get the normalization result of a render (whether increase or decrease in decibels), so that scripts could be made to automate batch normalization?

[Meo-Ada Mespotine]

Originally Posted by Dafarkias

Could we add an option in the API to get the normalization result of a render (whether increase or decrease in decibels), so that scripts could be made to automate batch normalization?

+1 from me.

Edit: and a way to automatically close the window after analysis has been finished, so it can be fully automatized.
Currently the window must be closed by hand unlike with normal renders, where closing automatically after the fact is possible.

[MrTsonts]

Originally Posted by Dafarkias

Could we add an option in the API to get the normalization result of a render (whether increase or decrease in decibels), so that scripts could be made to automate batch normalization?

+1

And on/off "Save copy of project to outfile.wav.RPP"

[mccrabney]

# MIDI note ordering: give more visual feedback about selected note [p=2450000]

looks great, thank you!

[lb0]

I'm having an issue with GetParam/SetParam API and JSFX.

This is a very recent issue - but not exactly sure when it cropped up.

It seems GetParam/SetParam are affecting the wrong sliders within the JSFX.

So I'm trying to toggle the value of a slider in a JSFX from 0 to 1 or 1 to 0. The slider I'm wanting to change is slider 48. Therefore I use a param index of 47 in the API calls (as they're zero based). I'm finding slider 49 changing - not slider 48... ??!!

Quick gif showing the issue:



I've not yet tested outside of this example...

[schwa]

Are any of the sliders unnamed or hidden? I think those will get skipped when counting to 47.

[lb0]

Originally Posted by schwa

Are any of the sliders unnamed or hidden? I think those will get skipped when counting to 47.

Yes - they're all hidden. What do you mean skipped?

Version 529 was working perfectly. versions since then have exhibited this behaviour (I believe).

[Funkybot]

Regarding my MIDI Note Name Order being lost after Glue bug: BFD3 is one of those plugins that reports note names to the host. If I update the keymap in BFD3, it gets written back to Reaper in near-realtime.

Is it possible that some events in Reaper [like a Glue] are causing BFD3 and similar plugins to resend the note name+order, which is overwriting the user's custom order? If that were the case, that could explain why the order gets lost so easily and hopefully there'd be a way to maintain the order.

[schwa]

Originally Posted by lb0

Yes - they're all hidden. What do you mean skipped?

Version 529 was working perfectly. versions since then have exhibited this behaviour (I believe).

Do the sliders all have names? Looking at the code, when deciding what the 48th jsfx parameter is, REAPER counts only sliders that have names. That's longstanding behavior.

[n997]

# MIDI editor: fix keyboard drawing glitches around top of view [p=2450683]

Thanks, appears to be fixed on my system as well.



Also, thanks for the Normalize feature!
A few weeks ago I was thinking of how useful that would be in REAPER, especially in batch runs, and now it's there.
Sometimes it seems like you are reading users' minds