v6.36+dev0921 - September 21 2021

[tonalstates]

v6.36+dev0921 - September 21 2021

• * Includes feature branch: multichannel, multi-mono, multi-stereo ReaPlugs
• * Includes feature branch: ReaLimit and render limiting
• * Includes feature branch: MIDI editor note reordering
• * Includes feature branch: media item lanes
• + Actions: duplicate selected items creates new groups when duplicating grouped items [t=257557]
• + Actions: duplicate selected items obeys item grouping
• + FX browser: scan for new LV2 plug-ins when refreshing list via F5 [t=257658]
• + Meters: consistent rounding behavior across all peak metering
• + ReaScript: MIDIEditor_GetTake and MIDIEditor_EnumTakes return nil if the MIDI editor is empty

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

[_Stevie_]

Originally Posted by tonalstates

[*]+ ReaScript: MIDIEditor_GetTake and MIDIEditor_EnumTakes return nil if the MIDI editor is empty

Thanks devs!!!

[chmaha]

Originally Posted by tonalstates

[*]+ Meters: consistent rounding behavior across all peak metering

Many thanks!

[nofish]

Originally Posted by tonalstates

[*]+ ReaScript: MIDIEditor_GetTake and MIDIEditor_EnumTakes return nil if the MIDI editor is empty

Now that was fast. :P Thanks!
edit: test ok here.

edit2:
Testing the two functions in conjunction (with a non-empty ME), maybe something unusual in the value display? (though it evaluates as valid take):





edit3:
Display changes running this 3-liner script consecutively.
screencapture

[schwa]

Originally Posted by tonalstates

+ Meters: consistent rounding behavior across all peak metering

There are some more changes coming on this, to prevent track meter clip indicators from incorrectly lighting due to rounding.

[Phazma]

Originally Posted by schwa

There are some more changes coming on this, to prevent track meter clip indicators from incorrectly lighting due to rounding.

Nice! Does this mean that the issue from this FR will be solved? https://forum.cockos.com/showthread.php?t=254171

[Reflected]

maybe it's just me but the following action doesn't work for me anymore:

Item properties: Pitch item up one semitone

anyone else?


EDIT: NVM - I disabled the "display media item pitch" option by mistake lmao

[Paul Eye]

Originally Posted by tonalstates

+ Meters: consistent rounding behavior across all peak metering

There's still a 0.1dB difference in LRA between the render stats and the JS loudness meter, as in my +dev9020 post:
https://forum.cockos.com/showpost.ph...5&postcount=35

Everything else looks good now, thanks

[daxliniere]

Originally Posted by schwa

There are some more changes coming on this, to prevent track meter clip indicators from incorrectly lighting due to rounding.

I think it would be a good idea if, when rendering a floating point file, >0dBFS was not flagged as clipping.

[Phazma]

Originally Posted by daxliniere

I think it would be a good idea if, when rendering a floating point file, >0dBFS was not flagged as clipping.

I disagree. It is helpful to know if a rendered float file is at risk of clipping a DA converter or being clipped when converted to fixed point. IMO the red lights should generally indicate “overs” and not neccessarily “clips”.

[daxliniere]

Originally Posted by Phazma

I disagree. It is helpful to know if a rendered float file is at risk of clipping a DA converter or being clipped when converted to fixed point. IMO the red lights should generally indicate “overs” and not neccessarily “clips”.

I will have to politely disagree with you on one point, Phazma. Floating-point files are not intended for 'consumption', they are a 'working file', therefore they should never be sent to a D/A. Sure, of course you can, but that's not what they're for.

Most importantly, I think we agree that >0dBFS may not always represent clipping in a floating-point audio stream and, in that situation, it should not have a big red warning.

[elcalen]

A couple things I noticed while playing around with ReaVerb and four channel IR files in 6.36+dev0920...

1. If I have two track channels and four plugin channels in ReaVerb in order to use a quad channel IR file, then if I later add more track channels—for example to set up auxiliary sidechain compression—those additional channel 3/4 pins appear to get automatically added to ReaVerb's pin mappings as well (to plugin in and out channels 3/4). Which is not really desirable. Is there any way around this?

2. The dropdown file selector under 'Load impulse response from path:' doesn't display the character '&', but replaces it with a period instead. (This is on Linux, in case that makes a difference for encoding stuff.) The 'Browse...' dialogue displays the file names correctly.

[schwa]

Originally Posted by nofish

maybe something unusual in the value display?

The watch list is telling you that your variables getTake and enumTakes are equivalent. The order switches based on what order the watch list happens to evaluate them.

[Phazma]

Yes I am aware that it is mostly used as an intermediate format which will be further processed and technically doesn’t clip at 0dBFS. But unless negative gain is applied at some stage before creating the final file it will clip, if there are peaks over 0dBFS..

Again, it comes down to whether we interpret the red lights as clipping or overs. And I would opt for interpreting them as overs and would be grateful for having this visual warning that tells my brain “attention, check the volume of this file, it could clip if you don’t lower it”.

In my opinion, who doesn’t care about this information can just ignore the lights, knowing that the render will not be clipped anyway.

If we want to be super fancy we would have orange lights for overs and red lights for clips but I can see that leading to feature creep.

Anyway, we both expressed our opinion, now it is up to the devs to decide. I just hope that in the next version the red lights will finally stay off when the peaks don’t exceed 0dBFS.

[Paul Eye]

Another test, LUFS-I difference of 0.1dB:



A render of the same project resulted in -11.9 LUFS-I, but that's probably just some inherent slight modulation differences (which are expected to happen).

[nofish]

Originally Posted by schwa

The watch list is telling you that your variables getTake and enumTakes are equivalent. The order switches based on what order the watch list happens to evaluate them.

Oh, thanks.
Never noticed this feature.

[Coachz]

Originally Posted by _Stevie_

Thanks devs!!!

Ohh, that sounds nice

[deeb]

Originally Posted by Phazma

Again, it comes down to whether we interpret the red lights as clipping or overs.

but 0db is clipping? i thought clipping and over was the same.

For me it would be much more useful if RED ment something is adding digital clipping and that i should lower the volume, otherwise i can't distinguish between being a useful volume which is 0db and something over it.

Also most samples and synth patches tend to be on 0DB and so all of them start by being RED in the meter and this is annoying.

[Phazma]

Originally Posted by deeb

but 0db is clipping?

Not when rendering to a floating point file. But google if it interests you, I am only going to mess this thread up if I try to explain it.

Otherwise (as previously described) I agree with what you that it is annoying if 0dB samples light up red.

[schwa]

Honestly track clip meters are not meaningful unless the track is sending to hardware or writing to file. And even then the meters are only somewhat meaningful.

[deeb]

Originally Posted by schwa

Honestly track clip meters are not meaningful unless the track is sending to hardware or writing to file. And even then the meters are only somewhat meaningful.

yes but when we are doing the composition/mixing process and we select the sounds and set respective volumes we want to know if that source can be render/freeze with no digital clipping and It's difficult to ignore a red dominant sign at each track meter specially when we can't easily know if something is ON SPOT at 0db or over it and so we tend to set volumes down even when there is no reason for that.

[Reflected]

Originally Posted by Phazma

I agree with what you that it is annoying if 0dB samples light up red.

I agree with that a lot~

[Nixon]

+ FX browser: scan for new LV2 plug-ins when refreshing list via F5 [t=257658]


thanks Justin this seems to work

one tiny nitpick is that at least on my setup the new plugins aren't listed under the new column.