v7.19+dev0731 - July 31 2024

[Edgemeal]

v7.19+dev0731 - July 31 2024
* Includes feature branch: FX automation overhaul
* Includes branch: internal buffering/antfx modernizations
* Includes branch: internal cleanups
* Includes feature branch: 128 track groups
* Includes feature branch: more combinations of peak display modes
* Includes feature branch: RGB profile tweak
* Includes feature branch: additional localization options
* Includes feature branch: extended ASCII encoding for .wav file text metadata
+ API: improve undo-dirty tagging of various item/take APIs
+ ARA: do not seek to loop start when setting loop points from ARA plugins
+ Automation: increase UI processing rates
+ Control surfaces: increase input reading rate [t=231630]
+ Lanes: when track has only one lane and it is not already playing, do not automatically set that lane playing after edits [t=293259]
+ Metronome/click: fix mouse behavior in click pattern editor with retina monitors and high time signatures
+ Render: show project regions in render peaks display
+ Tempo envelope: fix possible bad click pattern created when pencil-drawing tempo envelope points
+ Video: automatically refresh video processors that use input_get_name() when a track/take name changes [t=293212]
+ Video: fix loading presets via ReaScript when UI is hidden [t=293212]
# Render: improve behavior when creating time selection and mouse moves outside the window
# Tempo/time signature: fix inserting tempo change immediately before a time signature change [p=2799205]

Full Changelog - Pre-Releases - Feature Requests - Generated by WhatsNew2

[musicbynumbers]

Render: show project regions in render peaks display

Thanks!

[mozart999uk]

Whilst you're doing work on rendering and the window, do you think it might be possible to address this?

https://forum.cockos.com/showthread.php?t=258279

[_Stevie_]

OSC timer issue is still a thing with this build

[Buy One]

Originally Posted by Edgemeal

v7.19+dev0731 - July 31 2024

+ Video: automatically refresh video processors that use input_get_name() when a track/take name changes [t=293212]

+ Video: fix loading presets via ReaScript when UI is hidden [t=293212]

The second issue is fixed, thank you.

There's no improvement in the first unfortunately (the animation below).

What i tried as a workaround before this dev release was creation of new items in real time and copying to them an instance of the Video processor sitting in another track specifically for this purpose OR having an item with the Video processor set up located elsewhere and pasting its copies to the markers which are crossed by the playhead OR alternating bypass of two Video proc instances in the same take FX chain. These didn't work.

What works 100% is having separate items with Video processor instances inserted and different take names at key points ready, which is basically a static setup and which leads me to believe that the Video processor or the input_get_name() function processes content in advance and is unable to react to changes which haven't been pre-processed. Is this a more or less accurate understanding?

[Justin]

Originally Posted by _Stevie_

OSC timer issue is still a thing with this build

Was it fixed in 0729?

[Justin]

Originally Posted by Buy One

the Video processor or the input_get_name() function processes content in advance and is unable to react to changes which haven't been pre-processed. Is this a more or less accurate understanding?

That is correct, though the current builds detect changes in input names and tries to make sure those frames get re-rendered ASAP, but it still takes time.

[_Stevie_]

Originally Posted by Justin

Was it fixed in 0729?

It was not entirely, but only for (empty!) tracks.
Now, when there are more than 8-10 items in a project, the OSC timer slows down at the moment the cursor crosses those items.

[Justin]

Originally Posted by _Stevie_

It was not entirely, but only for (empty!) tracks.
Now, when there are more than 8-10 items in a project, the OSC timer slows down at the moment the cursor crosses those items.

Hmm can't duplicate that, can you post a .rpp that duplicates it (ideally with media, if any is required -- if MIDI items are sufficient that would be ideal)

[Buy One]

Originally Posted by Justin

That is correct, though the current builds detect changes in input names and tries to make sure those frames get re-rendered ASAP, but it still takes time.

OK, i guess no cigar then

[Justin]

Originally Posted by Buy One

OK, i guess no cigar then

If the change in behavior (catching changes to those names while stopped, etc) is a meaningful improvement for you let me know. Otherwise it's extra overhead that might be best avoided.

[Buy One]

Originally Posted by Justin

If the change in behavior (catching changes to those names while stopped, etc) is a meaningful improvement for you let me know. Otherwise it's extra overhead that might be best avoided.

Unfortunately it's not. And while stopped the immediate update isn't necessary, it's only in play mode that the change must occur at specific moments to accurately reflect time stamps defined by the user. So no need to include the changes in the official release. Appreciate the consideration and willingness to address this.

[_Stevie_]

Originally Posted by Justin

Hmm can't duplicate that, can you post a .rpp that duplicates it (ideally with media, if any is required -- if MIDI items are sufficient that would be ideal)

I'm sending you a video and the .rpp via mail!

[ferropop]

Not sure if it's related to the video processor, but the first frame on ffmpeg exports is always completely blank. Social media sites generally use frame 1 as the default thumbnail, and any video exported out of Reaper ends up with a black frame as the thumbnail as a result of this.

[Justin]

Originally Posted by ferropop

Not sure if it's related to the video processor, but the first frame on ffmpeg exports is always completely blank. Social media sites generally use frame 1 as the default thumbnail, and any video exported out of Reaper ends up with a black frame as the thumbnail as a result of this.

Just tested here and it generates a correct first frame, so:


What ffmpeg version? Does it do it if you use MJPEG as a codec rather than H264? Can you provide a minimal test project with media to reproduce?

[Justin]

Originally Posted by _Stevie_

I'm sending you a video and the .rpp via mail!

Received, thank you.


Using your .rpp (without the FX, though), and reaper.ini, on Windows 11, can't reproduce at all using 0731. Hmph. I'm using the default left/right-key actions to move the cursor.

First - try it with all FX offline, in case that changes anything.

Second - Can you try it without sws and other third-party extensions installed? It's not unusual for strange performance issues to come down to this :/

[_Stevie_]

Originally Posted by Justin

Received, thank you.


Using your .rpp (without the FX, though), and reaper.ini, on Windows 11, can't reproduce at all using 0731. Hmph. I'm using the default left/right-key actions to move the cursor.

First - try it with all FX offline, in case that changes anything.

Second - Can you try it without sws and other third-party extensions installed? It's not unusual for strange performance issues to come down to this :/

I think I located the issue. It's the screen resolution that causes it.
I'm running 5120 x 2160 here. Is that maybe the reason you cannot repro it?

Reducing the arrange canvas by resizing REAPER to half the size solves it
Is there anything that can be done here?

EDIT: dropped you another video via mail

[vsthem]

With the metronome improvements, has there been any discussion of allowing users to have 1/8th note clicks for a period of time? When keeping measures lined up with a score, I don't want to actually adjust the time sig or BPM, just to have the click work in 1/8 notes. Is this possible now outside of hacky solutions?

Thanks all!

[schwa]

Does it do what you want to set the click pattern to 2x?

[tonalstates]

Is it out of place to ask to be able to edit the time signature metronome pattern and also playback audio from the arrangement window? This when editing a tempo marker, I have a complex time signature and being able to hear and count the subdivisions while writing would be nice

[Reaktor:[Dave]]

Originally Posted by Edgemeal

+ Control surfaces: increase input reading rate [t=231630]

Cool to see this in the current pre-release!

Made some tests with v7.19 and v7.19+dev0731. The rate seems to have changed from ~30ms to ~15ms when logging time_precise from IReaperControlSurface::Run(). About right?

The first two tracks in the screenshot show the difference between both versions when calling TrackFX_SetParamNormalized() in Run() for every MIDI event in midi_input_device->GetReadBuf()->EnumItems(). Clearly, the rate got increased for dev0731. For reference, the time selection is exactly 1 second.


When feeding the MIDI events into a record-armed track using StuffMIDIMessage(), the rate still seems the same when comparing tracks 3 and 4. Any idea why there's no improvement here? (Why would you do this, anyway? The use case is an adaptive MIDI controller using REAPER's API to make its data and display fit automatically to all sorts of instruments in a project.)

Track 5 shows how the control surface MIDI events are fed to a track via a REAPER API aware CLAP plugin in the input FX. While this allows for "placing" the events with the event's offset information and increases the rate, the jitter is still quite strong. EDIT: This was wrong. The described approach works as good as recording MIDI events directly to a track, but it's a workaround requiring significant effort.

Finally, track 6 shows the events when REAPER records the MIDI data directly into a track. This one has both, a high rate (seems about the same as track 1?) and no jitter. Any idea for improvements or how we can get to that quality level for control surface plugins creating TCP parameter events or virtual MIDI events?

[pentecost]

Originally Posted by schwa

Does it do what you want to set the click pattern to 2x?

not to speak for OP- in my own case, globally, yes.
i just tweak tempo subdivisions to achieve localized changes, but a local multiplier within the marker dialog would also be welcome.

[deeb]

Originally Posted by pentecost

not to speak for OP- in my own case, globally, yes.
i just tweak tempo subdivisions to achieve localized changes, but a local multiplier within the marker dialog would also be welcome.

maybe could be considered: 2x 4x 0.5x 0.25x and possibly more.

[Justin]

Originally Posted by _Stevie_

I think I located the issue. It's the screen resolution that causes it.
I'm running 5120 x 2160 here. Is that maybe the reason you cannot repro it?

Reducing the arrange canvas by resizing REAPER to half the size solves it
Is there anything that can be done here?

EDIT: dropped you another video via mail

ah I think I have a couple of ideas on this, I'll try the cleanest of the two for the next build.

[deeb]

+ Video: automatically refresh video processors that use input_get_name() when a track/take name changes

Looking forward to try this. Does this mean take name (notes) will be read in a single video processor loaded on a track?

[_Stevie_]

Originally Posted by Justin

ah I think I have a couple of ideas on this, I'll try the cleanest of the two for the next build.

Justin, you are my hero, thanks! <3

[Reaktor:[Dave]]

Originally Posted by Reaktor:[Dave]

Any idea for improvements or how we can get to that quality level for control surface plugins creating TCP parameter events or virtual MIDI events?

I wonder if it would improve the situation at least post-record if functions like TrackFX_SetParamNormalized() or StuffMIDIMessage() could get an expanded version with support for handing over the MIDI offset?

[mschnell]

Originally Posted by Reaktor:[Dave]

Finally, track 6 shows the events when REAPER records the MIDI data directly into a track. This one has both, a high rate (seems about the same as track 1?) and no jitter. Any idea for improvements or how we can get to that quality level for control surface plugins creating TCP parameter events or virtual MIDI events?

Midi events are handled with at much accuracy as the hardware provides and stored with sample accuracy.

By definition Midi and audio are "virtual realtime" stuff (timing tied to the streams of sample blocks ), while parameter Modulation is not (timing mostly according to the "wall clock"). Hence Midi and audio are always handled using PDC etc: if the CPU power (and latency setting) are not sufficient, you get crackling, but no "erroneous" behavior. With parameter modulation this is different: value changes can be dropped.

Hence it would be better to record Midi, if high time resolution is needed.

[splitting_ears]

The new render window improvements are great, thank you!

Just a small UI suggestion: wouldn't it make sense to move these options from the Stats/Charts/Display button to the right-click menu on the peak display itself? I think it would feel more logical.

[Reaktor:[Dave]]

Originally Posted by mschnell

Midi events are handled with at much accuracy as the hardware provides and stored with sample accuracy.

That's why I suggested to allow control surface plugins to express a MIDI event's offset in the relevant APIs which should help at least post-recording. When the control surface plugin looks into the event queue, it'll likely find multiple events for the same control and has no way to tell Reaper when these events happened originally. See here for how there is a problem with recording parameter automation [1] and here for how the result is much better when the data is recorded to a MIDI clip instead [2].

In the end, control surface plugins should process and alter MIDI data from and to a control surface. Reducing the quality of the event queue (lower rate, more jitter) should be avoided. Whether the MIDI data goes to a track or its envelopes shouldn't affect the quality of the event queue.

[1] https://forum.cockos.com/showthread.php?t=231630
[2] https://forum.cockos.com/showthread.php?t=272125

[vsthem]

Originally Posted by schwa

Does it do what you want to set the click pattern to 2x?

always appreciate you responding on here.

I just found that option. It DOES do what I want, but then I'm finding that I need to constantly fiddle with the metronome pattern when it's doubled for the whole session. It'd be nice if there was a 2x metronome option per time sig change (override). The double metronome time is likely only to be needed 1 or 2 times in a session, so it'd be nice to not have it doubled throughout.

Totally get that this likely falls into the "nice to have" category.

Appreciate all your work on here!

[soundfield]

Originally Posted by splitting_ears

The new render window improvements are great, thank you!

Just a small UI suggestion: wouldn't it make sense to move these options from the Stats/Charts/Display button to the right-click menu on the peak display itself? I think it would feel more logical.

I totally agree... this new render window is amazing.

UI : Also agree, right click was my first instinct looking at the new plot for the first time,
I found it soon after 😅. Maybe both 🤷‍♂️ Good idea! +1 👍

[dangguidan]

# Tempo/time signature: fix inserting tempo change immediately before a time signature change

This action is different from before, as it only inserted tempo information without inserting beats.

[schwa]

Originally Posted by dangguidan

This action is different from before, as it only inserted tempo information without inserting beats.

Can you be more specific, please?

[dangguidan]

This action is different from before:
Tempo envelope: Insert tempo marker at edit cursor, without opening tempo edit dialog

before:


now:

[schwa]

Originally Posted by dangguidan

This action is different from before:
Tempo envelope: Insert tempo marker at edit cursor, without opening tempo edit dialog

Fixing, thanks!