v7.22+dev0903a - September 3 2024

[sockmonkey72]

v7.22+dev0903a - September 3 2024

• * Includes feature branch: batch converter updates
• * Includes feature branch: auto-bypass plug-ins with PDC when record armed
• * Includes feature branch: time signature marker editing improvements
• * Includes feature branch: additional render normalization options
• * Includes feature branch: render display improvements
• * Includes feature branch: FX automation overhaul
• * Includes branch: internal cleanups
• * Includes feature branch: 128 track groups
• * Includes feature branch: more combinations of peak display modes
• * Includes feature branch: additional localization options
• * Includes feature branch: extended ASCII encoding for .wav file text metadata
• + API: add IsWindowTextField() for extension use
• + API: update hwnd_info hook to allow more context for window information
• + Project tabs: improve play state indicator state during/after render [t=293403]
• + Project tabs: show/hide item notes windows when switching tabs [t=293740]
• # Batch converter: fix output when not imploding channels

v7.22+dev0903 - September 3 2024

• * Includes feature branch: batch converter updates
• * Includes feature branch: auto-bypass plug-ins with PDC when record armed
• * Includes feature branch: time signature marker editing improvements
• * Includes feature branch: additional render normalization options
• * Includes feature branch: render display improvements
• * Includes feature branch: FX automation overhaul
• * Includes branch: internal cleanups
• * Includes feature branch: 128 track groups
• * Includes feature branch: more combinations of peak display modes
• * Includes feature branch: additional localization options
• * Includes feature branch: extended ASCII encoding for .wav file text metadata
• + Batch converter: improve responsiveness with very large numbers of files
• + MIDI editor: fix rounding inconsistencies of action to adjust MIDI event velocity
• + Normalize: add setting to adjust mono media an additional -3dB when normalizing media items, rendering, or converting
• + Normalize: consistent wording for all normalize actions and dropdowns ("normalize each separately" vs "normalize to loudest")
• + Normalize: improve precision of action to normalize media items using common gain
• + Peaks: improve appearance of loudness graph when zoomed in
• + Peaks: support opacity control for loudness graph
• + Project tabs: when a playing background project stops at end of project, do not stop playing foreground project
• + Render window: do not corrupt UTF-8 characters in UI controls [t=294123]
• + VST: ignore programs for VST3s with a single program [t=294090]
• + VST: improve tcp/mcp click behavior of gui-less bridged plug-ins [t=293994]
• # Batch converter: fix crash when right-clicking empty area of file list
• # Menus: enable paste-to-takes in menus when files are on clipboard
• # Normalize: respect preference to normalize all takes when not using common gain
• # Peaks display settings window: improve ... menu when displaying multiple peak types
• # Peaks: fix opacity setting when coloring peaks by loudness

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

[F1308]

THIS ONE IS A VERY GOOD ONE !!!!

😀😀😀😀
🎹🎹🎹🎹

[akademie]

Batch Converter is seriously broken in this +dev0903 (x64) release !!!

First I tried to convert WAV 48k to MP3 (192kbps) 44.1k it took ages then after finishing whole Reaper app vanished Resulting file was silence.

Then after restarting crashed Reaper I tried more - MP3 (320kbps), FLAC 48k, they were finished immediately (like 0.5 sec) with 1-2kB output MP3 / FLAC files.

I also tried to convert without resampling, so set output = source samplerate and it took the usual time for converting, but finished file was only buzz

[schwa]

The +dev0903a build that was just posted will hopefully fix the batch converter issues.

[Buy One]

Originally Posted by sockmonkey72

v7.22+dev0903 - September 3 2024

• + VST: ignore programs for VST3s with a single program [t=294090]

I'm aware of its being an extremely remote corner case but just so you know that even when ignored if i by pure happenstance name a custom preset identically to the ignored and hidden factory preset, FX_GetPresetIndex() will return -1 when such preset is selected, FX_GetPreset() will return blank preset name and FX_NavigatePresets() won't navigate further.

[akademie]

Originally Posted by schwa

The +dev0903a build that was just posted will hopefully fix the batch converter issues.

Confirming that BC is fixed and is converting normally again
Thanks

When BC is part of +dev now, I just filed a FR for silently incrementing filename in main BC window here :
Adding 'Silently increment filenames' option in main BC window
https://forum.cockos.com/showthread.php?t=294156

[BPBaker]

Originally Posted by sockmonkey72

v7.22+dev0903a - September 3 2024[*]+ Normalize: add setting to adjust mono media an additional -3dB when normalizing media items, rendering, or converting

Amazing and thank you so much! I'll be testing this in a project later today.

[*]+ Normalize: consistent wording for all normalize actions and dropdowns ("normalize each separately" vs "normalize to loudest")

FWIW, I find the change to "normalize to loudest" more confusing or maybe less clear. Is this doing the same thing as "normalize to common gain?" If it's the same function, did "common gain" always measure based on the loudest item in the group of selected items, or did it measure the group of items as a whole and then apply normalization? I had assumed the latter (and think I prefer it, if there is a difference in measurement/processing between the two.)

EDIT: I'm now realizing that "normalize to loudest" makes a lot more sense when you're talking about traditional peak normalization. But when it comes to LUFS normalization, my feeling is that this is more confusing and/or this wording doesn't fit both use cases as precisely.

[*]+ Normalize: improve precision of action to normalize media items using common gain

Just curious what's changed about this, and if it relates to the question above?

[*]+ Peaks: support opacity control for loudness graph
...[*]# Peaks display settings window: improve ... menu when displaying multiple peak types[*]# Peaks: fix opacity setting when coloring peaks by loudness

Speaking of peaks readability and opacity, lately I've been feeling Reaper could do a clearer job representing layers of peaks when editing items that overlap and/or crossfade with one another--e.g. with differently tweaked opacity/transparency settings. (Perhaps this could only happen when the mouse button is being pressed down during an overlapping edit and change back to normal on mouse-up?)

Ideally, I'd like to be able to see the peaks of both items layered on top of one another for the entire length of the overlap in order to properly align peaks/transients.

EDIT: After reflecting on this, I think my issue also has something to do with how the peaks amplitude changes along with item fades when crossfading--which is a feature I love about Reaper generally speaking. But while editing crossfades, however, these fade visualizations prevent you from seeing the "true" peaks of overlapping items along the entire length of the overlap, so it's harder to see how transients will line up across the whole length of the crossfade. Maybe there's something that could be done with opacity settings to better visualize the complete overlaps while also still having the fades show the change in peaks amplitude? (I want to have it both ways!) :-)

[schwa]

Originally Posted by BPBaker

Is this doing the same thing as "normalize to common gain?" If it's the same function, did "common gain" always measure based on the loudest item in the group of selected items, or did it measure the group of items as a whole and then apply normalization?

For media items, the setting labeled "common gain" previously measured the group of items as a whole, but for rendering, the setting labeled "common gain" normalized all files relative to the loudest file. This change makes both scenarios behave the same way. The "consistent wording" and "improve precision" changelog lines both refer to the same general change.

One problem with the previous common gain behavior for media items is that the loudness measurement could differ depending on what order the items are measured in.

[BPBaker]

Originally Posted by schwa

For media items, the setting labeled "common gain" previously measured the group of items as a whole, but for rendering, the setting labeled "common gain" normalized all files relative to the loudest file. This change makes both scenarios behave the same way. The "consistent wording" and "improve precision" changelog lines both refer to the same general change.

One problem with the previous common gain behavior for media items is that the loudness measurement could differ depending on what order the items are measured in.

Interesting. I'll have to digest this and also obviously test it. But my intuition is that for my most frequently used use case (LUFS normalizing phrases of dialogue which are often made up of many small items edited from the same reference file) this could create unpredictable/undesirable results. I'll give it a whirl and let you know how it goes!

[BPBaker]

Originally Posted by schwa

For media items, the setting labeled "common gain" previously measured the group of items as a whole...
...
One problem with the previous common gain behavior for media items is that the loudness measurement could differ depending on what order the items are measured in.

Based on a quick test, this does indeed seem to change things in a way that's undesirable for LUFS-i normalization.

For instance, imagine an editing sequence of dialogue where one short item in the group is significantly louder than the others (e.g. someone laughs).

With the old common gain behavior, my understanding is that the loud item would be measured in context with its surrounding items, measured together, and the gain would be applied to the group as a whole. Meaning the overall LUFS-i loudness for the phrase would match other edited phrases using the same technique.

But with this new behavior where the entire phrase is adjusted to the loudest item, the sequence of items is actually adjusted to a quieter LUFS average. Not only will the majority of the items in the sequence not reflect the intended LUFS average for the phrase, but there will be significant loudness variations from phrase to phrase in comparison to other LUFS-i normalized sequences.

I wasn't aware that the previous measurement could vary based on order of items--obviously that's not desirable either. But this change effectively breaks a big part of my loudness workflow at the moment.

[EvilDragon]

While I still do get "not responding" while importing 200k files into batch converter (may be good to combat that with at least SOME kind of progress throbber of sorts?), it did not hang forever and eventually it imported the lot, in I think roughly 20ish seconds. Many thanks!

[AZpercussion]

I really agree with BPBaker. Combining items in phrases is a must have for dialogue editing.

[schwa]

Originally Posted by EvilDragon

While I still do get "not responding" while importing 200k files into batch converter (may be good to combat that with at least SOME kind of progress throbber of sorts?), it did not hang forever and eventually it imported the lot, in I think roughly 20ish seconds. Many thanks!

For me, importing 200k files into the batch converter takes about 0.8 seconds on a decent but by no means super-powered Windows machine. That's 20 folders with 10k files each. Are you importing a complex folder structure? Could you post your reaper.ini file?

[EvilDragon]

I am dropping one folder that contains 18 subfolders, each of which contains 14 folders, each of which has a varying number of samples (from 60 to 2500ish).

INI attached!


My machine is the same for the past 7 or so years: i7-6700K@4.3 GHz, 64 GB RAM, a bunch of SSDs (altho in this case samples are on a rust drive - maybe I should check this out, I bet it does make a difference).

[schwa]

Originally Posted by EvilDragon

My machine is the same for the past 7 or so years: i7-6700K@4.3 GHz, 64 GB RAM, a bunch of SSDs (altho in this case samples are on a rust drive - maybe I should check this out, I bet it does make a difference).

If you have the space available, it's worth trying copying the files to a SSD and importing from there.

[EvilDragon]

I think I will manage.

(Last four are spinning rust tho )

[EvilDragon]

Was about 3-4 seconds with no "not responding" from an SSD!

I think that's quite great, thank you, schwa!

[X-Raym]

Hi,


In reascript API doc, CountSelectedMediaItems is marked as deprecated

DEPRECATED - Do not use in new code. count the number of selected items i

This is an essential function in almost all reascripts, how can it be deprecated ? 😮.and what replace it ?

[Buy One]

Originally Posted by X-Raym

Hi,

In reascript API doc, CountSelectedMediaItems is marked as deprecated

This is an essential function in almost all reascripts, how can it be deprecated ? 😮.and what replace it ?

Full warning

DEPRECATED - Do not use in new code. count the number of selected items in the project (proj=0 for active project)

For GetSelectedMediaItem() as well

reaper.GetSelectedMediaItem( ReaProject proj, integer selitem)

DEPRECATED - Do not use in new code. get a selected item by selected item count (zero-based) (proj=0 for active project)

But the warnings seem to recommend using these very functions because counting all selected items in the project and getting selected item by selected items 0-based count is how it's always been done (as far as i remember anyway)

Or should ReaScript API doc in dev builds be ignored because it's not meant for end users?

[schwa]

reaper.GetSelectedMediaItem( ReaProject proj, integer selitem)

DEPRECATED - Do not use in new code. get a selected item by selected item count (zero-based) (proj=0 for active project)

The first sentence is the deprecated message, and the second sentence is the usage of the deprecated function. The second sentence is not a recommendation for something else to use instead of the deprecated function.

The deprecated functions still work, but they are (and have always been) horribly inefficient. It's much better for calling code to iterate over all media items and skip unselected items. (edit: see post #26 for more information)

[Buy One]

Originally Posted by schwa

The first sentence is the deprecated message, and the second sentence is the usage of the deprecated function. The second sentence is not a recommendation for something else to use instead of the deprecated function.

The deprecated functions still work, but they are (and have always been) horribly inefficient. It's much better for calling code to iterate over all media items and skip unselected items.

The first sentence sounds like a prohibition as if something might go wrong if it's used. This is not the wording for other deprecated functions.

Deprecated functions aren't born inefficient or are they, or do they become inefficient with passage of time?

Placing the two sentences on separate lines while the DEPRECATED message is preceded by usage description would make the description so much clearer.

[schwa]

Originally Posted by Buy One

The first sentence sounds like a prohibition as if something might go wrong if it's used.

Deprecated functions aren't born inefficient or are they, or do they become inefficient with passage of time?

Placing the two sentences on separate lines while the DEPRECATED message is preceded by usage description would make the description so much clearer.

We'll improve the documentation. These particular functions were born inefficient, we should not have added them in the first place.

[Buy One]

Thank you.

Interesting, after so many years and so many written scripts LOL. And i asked because i had never come across a recommendation to avoid them.

BTW if i needed to get a selected item with particular index or the very 1st only, would using the Get function still be inefficient?


-------------
Previous reference to item selection functions optimization v7.001+dev1017 - October 17 2023

[X-Raym]

We'll improve the documentation. These particular functions were born inefficient, we should not have added them in the first place.

I'm not sure how inneficient is in terms of milliseconds, but I have use CountSelectedMediaItems in 789 occurences in my scripts and GetSelectedMediaItems 661. These functions are core to ReaScripting, they don't seem to be that unefficient, at least, not enough to consider it deprecated (aka: not use them in the future) IMHO.


The "good way" would be to just use CountMediaItems and then GetMediaItem and checking for IsMediaItemSelected ?


Maybe someone can benchmark these against the deprecated method? How many items before it get noticeably inefficient ?

[X-Raym]

Interesting, after so many years and so many written scripts LOL.

Yes, and all reascripts tutorial ever written and recorded since mine in 2015 clearly showcase these functions ^^
They may not be the most optimum but they are totally usable for sure. I really never saw them as the slow part of any script, even when performing on 10 000 items.

[schwa]

I mean, you can just trust us that it's better to use a different function . In v7.03 Justin added some caching to improve performance, but the problem with adding a poorly thought out API function in the first place (my error in v3.11 :/) is that you are forever paying for it. Our internal chat on this subject includes the comment "throwing good code after bad".

[OLSHALOM]

Originally Posted by X-Raym

The "good way" would be to just use CountMediaItems and then GetMediaItem and checking for IsMediaItemSelected ?

Not after optimization of the functions in 7.03.

[X-Raym]

Originally Posted by schwa

I mean, you can just trust us that it's better to use a different function

Considering how much this function is used, it would be nice to know "how much better". :P Cause IMHO, flagging as deprecated is strong word. Maybe there just could be a noticed to say "Use GetMediaItem for best performance", instead of "DEPRECATED - Do not use in new code."


EDIT: Wait wrong benchmark results

[X-Raym]

Here is benchmark code, with a function to store selected items in a table

function GetSelectedMediaItems_a(proj)
  local t = {}
  for i = 0, reaper.CountSelectedMediaItems(proj) - 1 do
    t[i+1] = reaper.GetSelectedMediaItem(proj, i)
  end
  return t
end

function GetSelectedMediaItems_b(proj)
  local t = {}
  local index = 1 -- we do not use table.insert which is slow
  for i = 0, reaper.CountMediaItems(proj) - 1 do
    local item = reaper.GetMediaItem( proj, i )
    if reaper.IsMediaItemSelected( item ) then
      t[index] = item
      index = index + 1
    end
  end
  return t
end


time_b = reaper.time_precise()
GetSelectedMediaItems_b(proj)
result_b = reaper.time_precise() - time_b

time_a = reaper.time_precise()
GetSelectedMediaItems_a(proj)
result_a = reaper.time_precise() - time_a

Run on 50 000 items, the GetSelectedMediaItem way is 1000 faster when no selection. When item are selected, it is more similar but still faster (by 0.008 approx).




If GetSelectedMediaItem isn't slower in every situation, I think Deprecation is too strong. but maybe I miss something in my tests ?

[OLSHALOM]

Originally Posted by X-Raym

Run on 50 000 items, the GetSelectedMediaItem way is 1000 faster when no selection. When item are selected, it is more similar but still faster (by 0.008 approx).

After the optimizations of CountSelectedMediaItems() and GetSelectedMediaItems() released in 7.03 it's always faster than using GetMediaItem() along with IsMediaItemSelected()

[OLSHALOM]

Originally Posted by schwa

The deprecated functions still work, but they are (and have always been) horribly inefficient. It's much better for calling code to iterate over all media items and skip unselected items.

When I may allow myself to say, after the optimization of CountSelectedMediaItems() and GetSelectedMediaItem() in 7.03 that's not the case anymore.

Because of the need of IsMediaItemSelected() by iterating thru all media items, it's faster to use GetSelectedMediaItems(). Especially for huge projects.

The optimization brought up a big benefit in efficiency when GetSelectedMediaItem() is used in a script and a big amount of items are selected.

Imo GetSelectedMediaItems() is the best we have at the moment.
Or does "deprecated" means a better function is coming?

[akademie]

Originally Posted by sockmonkey72

v7.22+dev0903a - September 3 2024

• + Project tabs: improve play state indicator state during/after render [t=293403]
• + Project tabs: show/hide item notes windows when

Thanks,
but more response in these individual threads please:

Empty Item windows from other tabs are not hidden

project tab play indicator keeps active after rendering

[Denys]

I am encountering a weird issue of CC Lane doubling in this version. I think I'm doing everything as usual, but it seems to behave differently.


Here is what happening on the following video:



1. Record MIDI CC Events with a MIDI keyboard.
2. Make sure it's the only CC Lane with events
3. Create new events with the mouse
4. The existing CC1 Event isn't affected and a new lane seems to be created.


https://i.imgur.com/qJPcVfI.mp4


I sent the project to support@cockos.

[mschnell]

I always have trouble when modifying a CC curve by mouse dragging, even when it had been created by mouse before.
As I do such only rarely I thought it was just me being inappropriately trained. But maybe this in fact is some kind of issue.

[Denys]

I'm noticing another issue that may not be specific to this version: Envelope Value doesn't refresh in TCP when I use CMD+Z. I have to click on the fader to make it refresh.

Off-topic: @mschnell: I agree there is room for improvement on MIDI enveloppes. I don't know if it's because I changed the default behaviour across the years, but when I have to use Studio One or Logic, enveloppe editing seems very smooth. In Reaper I still have a high rate of misclicks and strange behaviours (for instance not selected segments moving when I try to move a point, straight curves whereas Bezier is the default, etc.). I wanted to make a specific post about MIDI CC Lanes but I can't really explain why the experience is more pleasant in other softwares as I don't see how it wouldn't be completely reproducible in Reaper, thanks to mouse modifers, etc.