v6.72+dev1220 - December 20 2022

[STOP]

v6.72+dev1220 - December 20 2022

• * Includes feature branch: selected media item appearance changes
• * Includes feature branch: media item fixed lanes
• + API: add midi editor play cursor preview override API for playtime
• + Audio devices: fix input/output audio channel aliasing when only removing some outputs [t=273424]
• + Grouping: improve some corner case behaviors when track media/razor edit groups are used in addition to automatically grouping selected tracks
• + Media explorer: avoid freeze/redraw when accidentally doing a tiny file drag from file list
• + Media explorer: avoid temporary freeze when accidentally doing a tiny drag from playback preview area
• + Media items: improve display performance when media items have many take markers outside the visible bounds of the item [t=273948]
• + Peak building: fix corner case where peaks would fail to build for some media [t=273919]
• + Razor edit: fix deleting areas on master track envelopes with ripple-all-tracks enabled [p=2625216]
• + Razor edits: fix grouped preview on FIPM and fixed-lane tracks
• + Razor edits: fix grouped preview on FIPM tracks
• + ReaScript: add MEDIA_EDIT_LEAD/MEDIA_EDIT_FOLLOW to documentation for GetSetTrackGroupMembership, etc
• + Render: improve speed of writing outfile.render_stats.html when rendering many files at once [t=273917]
• # Grouping: prevent weirdness when grouping razor edits on envelope lanes of fixed lane tracks [p=2625549]
• # IDEs/ReaScript: improve/fix win32 international keyboard issues
• # Media items: clear grouped item selection preview when disabling item grouping via action
• # Media items: make preference to display grouped selection preview enabled by default
  

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

[PitchSlap]

I've noticed render window loudness stats can be way off.
They are correct when the render is finished, but don't seem to always update during (noticed with multiple projects.)
Also maybe it's resolution dependent, but there's more than enough space in the column to write "TruePeak"

[Zeno]

IMO there is no benefit to displaying the current values numerically, since no one can read them that quickly unless the time constants of the dynamics processor are set quite high. Currently, it just adds a lot of clutter when the GR values are running up and down like crazy all over the mixer.

My suggestion:
For the numeric GR value I would prefer a max hold. Preferably on the left side of the meter. As the scale of the meter adjusts to an increasing gain reduction, this provides a clear view of the meter bar.
It shows the max value, holds it for - let's say 3 or 5 sec - and then releases it.

If the meter bar additionally draws a small vertical line as an indicator for the max hold position, we have a ton of information.

1. We know the numeric max value.
2. We have an indicator of where the max value is on the meter bar.
3. We have a red bar as an indicator of where the current value is on the meter.
4. From these 3 pieces of information, it is possible to derive quite precisely which current value the red meter bar displays in relation to the max value.

...

[Embass]

[Embass]

[thommazk]

• + Media items: improve display performance when media items have many take markers outside the visible bounds of the item [t=273948]
  

It's fixed and it's great now, thanks a lot! ♥

[airon]

Gain reduction is a general indicator. Peak is the only number I'd ever be interested in. The rest is covered by the actual meter, which only needs to rise quickly. Sort of like an RTW gas peak meter.

It is extremely rare now that I ever look at the numbers.

[bolgwrad]

Is it intended that (since the column view mod) the render stats on-the-fly display is no longer available, or is there a setting?
[edit]

[Tale]

# IDEs/ReaScript: improve/fix win32 international keyboard issues

Yeah, now I can type double quotes, accented letters, etc. again. Thanks!

[alphoc]

Originally Posted by Embass

Off topic, but what exactly is this? Which feature? Numbers 1 and 2 on TCP, two items on the same track..is it a new feature?

[stillshaded]

Originally Posted by STOP

[*]+ API: add midi editor play cursor preview override API for playtime

Interesting. How does this work exactly? Is there anyway this could be used to create a midi scrub action that doesn’t move the play cursor? Probably not, but just checking. I’ve been looking for a way to do this since I started using reaper, which is the way midi scrub works in fl studio.

[vitalker]

Originally Posted by alphoc

Off topic, but what exactly is this? Which feature? Numbers 1 and 2 on TCP, two items on the same track..is it a new feature?

Read purple lines in the first post.

[alphoc]

OK, it's a new feature, now I understand why I didn't see it before :-)

[vitalker]

Originally Posted by alphoc

OK, it's a new feature, now I understand why I didn't see it before :-)

Not quite. It's been in dev builds for quite a while.

I believe this it the first build, where it appeared:
https://forum.cockos.com/showthread.php?t=250266
Wow, almost 2 years ago.

[bolgwrad]

Wow indeed.

[AZpercussion]

This bug exist in latest official release, but as autogrouping still on table, I write here:

[vitalker]

Originally Posted by AZpercussion

This bug exist in latest official release, but as autogrouping still on table, I write here:

I guess it's the same: https://forum.cockos.com/showthread.php?t=273993

[Mercado_Negro]

Originally Posted by Zeno

IMO there is no benefit to displaying the current values numerically, since no one can read them that quickly unless the time constants of the dynamics processor are set quite high. Currently, it just adds a lot of clutter when the GR values are running up and down like crazy all over the mixer.

My suggestion:
For the numeric GR value I would prefer a max hold. Preferably on the left side of the meter. As the scale of the meter adjusts to an increasing gain reduction, this provides a clear view of the meter bar.
It shows the max value, holds it for - let's say 3 or 5 sec - and then releases it.

If the meter bar additionally draws a small vertical line as an indicator for the max hold position, we have a ton of information.

1. We know the numeric max value.
2. We have an indicator of where the max value is on the meter bar.
3. We have a red bar as an indicator of where the current value is on the meter.
4. From these 3 pieces of information, it is possible to derive quite precisely which current value the red meter bar displays in relation to the max value.

...

Wholeheartedly agree.

[JRTaylorMusic]

Would be nice though if it had the same peak hold options as the regular meters.

[ferropop]

Even some steps indicating 3dB increments of GR would be easy enough to read, in lieu of displaying the number. Like a 1-pixel vertical tint every 3dB...

[Zeno]

Originally Posted by ferropop

Even some steps indicating 3dB increments of GR would be easy enough to read, in lieu of displaying the number. Like a 1-pixel vertical tint every 3dB...

Basically a good idea, but there is a catch. I've seen this done on some jsfx, but it only works if the scale has a fixed total range, which is not the case here (which I like). This means that as the GR increases, the number of notches would either have to be multiplied (if the range increases from 6dB to 24dB, the number of notches quadruples) or the reference value of the notches would shift (instead of one notch per 3dB, it would suddenly be 12dB). Both variants would not be very useful in practice. Option 1 adds unnecessary clutter and option 2 forces you to open the plugin UI as a reference, which undermines the whole point of an embedded meter.

The current implementation is also anything but useful, as the numeric GR readout obstructs the view of the meter bar and adds no useful information for the user. I really hope the devs will reconsider their concept until the final implementation in an official release build.

I may be a bit biased here, but I really think the concept I presented in post #3 objectively provides the most information for the user with a minimum of clutter. And it is very easy to implement. The one compromise I made here is the nomenclature. Minus "-" instead of "GR: " may not be wrong, but it is far from perfect. On the other hand, it saves 3 characters and thus takes up less space, which is good for the meter readability.

...