v7.23rc4 - September 27 2024

[smandrap]

v7.23rc4 - September 27 2024

• * 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
• + ReaScript: dpcument gfx.mouse_cap modifier key flags for both Windows and macOS regardless of which OS the documentation is generated on
• + Render: fix possibly incorrect rendered file when rendering with "preserve source media sample rate if possibe" enabled
• # Automation: improvements to drawing of node points in retina mode, clipped node points in general
• # Render window: add more accessibility labels

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]

Another one going very well.

😀😀😀😀
🎹🎹🎹🎹

[bolgwrad]

The 'Dry Run' window isn't indicating 'no output', I missed if that was on purpose.

[Daodan]

Originally Posted by smandrap

v7.23rc4 - September 27 2024

• # Automation: improvements to drawing of node points in retina mode, clipped node points in general

Default scaling (1.0), envelope height minimized.
Small holes appear at the top points.


Any scaling, at these angles the point is half filled.


Also, if two points are in the same place (overlapping) and there is another point after them, it looks like this:

[deeb]

Justin: could you check if anything changed for this to happen?

I am not sure when but i think this was not happening months ago:



i am using reaper.CSurf_OnVolumeChange(tr, value_s1, false) on a track set to touch.

(sorry this is in RC)

[Justin]

Originally Posted by deeb

Justin: could you check if anything changed for this to happen?

I am not sure when but i think this was not happening months ago:



i am using reaper.CSurf_OnVolumeChange(tr, value_s1, false) on a track set to touch.

(sorry this is in RC)

Just checked 7.04 and it behaves the same (assuming you have the same env writing options set). I think you want to use the SetTrackUIVolume() function instead.

[Justin]

Originally Posted by Daodan

Default scaling (1.0), envelope height minimized.
Small holes appear at the top points.

Heh yeah this can be tweaked.

Any scaling, at these angles the point is half filled.

This will have to be fixed after 7.23

Also, if two points are in the same place (overlapping) and there is another point after them, it looks like this:

interesting, looking into that one now, probably will be fixed after 7.23 too

[deeb]

Originally Posted by Justin

Just checked 7.04 and it behaves the same (assuming you have the same env writing options set). I think you want to use the SetTrackUIVolume() function instead.

Thank you very much for checking this out. hmm i don't know then, i am picking up an old lua project and maybe my memory tricking me and nothing changed in this regard. Anyway: i used SetTrackUIVolume() as you suggested instead of reaper.CSurf_OnVolumeChange() but the behaviour is the same. The curious thing is that if track is in write mode both SetTrackUIVolume() and reaper.CSurf_OnVolumeChange() apparently work as expected. This just happens with touch mode as far as i know. The curious thing is that with reaper.CSurf_OnSendVolumeChange() it also works fine in touch mode. So I assume something wrong specifically with volume touch(writting) functions.

The behaviour is that it doesn't replace old automation and instead it kind of merges with existing automation.

[airon]

Originally Posted by deeb

Thank you very much for checking this out. hmm i don't know then, i am picking up an old lua project and maybe my memory tricking me and nothing changed in this regard. Anyway: i used SetTrackUIVolume() as you suggested instead of reaper.CSurf_OnVolumeChange() but the behaviour is the same. The curious thing is that if track is in write mode both SetTrackUIVolume() and reaper.CSurf_OnVolumeChange() apparently work as expected. This just happens with touch mode as far as i know. The curious thing is that with reaper.CSurf_OnSendVolumeChange() it also works fine in touch mode. So I assume something wrong specifically with volume touch(writting) functions.

The behaviour is that it doesn't replace old automation and instead it kind of merges with existing automation.

That is very interesting. Using CSI I thought my USB cables or controller unit were crap, but it could be THIS ? Hmm.

Then again, this seems to have disapeared for 7.23rc4. Only a few weeks ago I was getting what you got Deeb. I just loaded up my 10-episode anime mix and all was fine in Touch mode. Devils work I tell ya.

[mschnell]

To me these automation modes plus the (automatic ?) selecting or copying Volume and/or Trim curves as target and/or source is rather confusing (OK, I should read the Guide ). (I normally don't do more than draw Volume curves by Mouse, but when I added a Control Surface Device to my setup by CSI, those things got confusing and not really usable. Even more so, as Volume wants to be controlled by Motor Faders, who feature touch sensitivity, and pan wants to be controlled by rotaries with LED ring, who dont.)

When it now comes to automating the automation by scripting it seems likely that the confusion grows - be there any Reaper glitches or not .

[Justin]

Originally Posted by deeb

Thank you very much for checking this out. hmm i don't know then, i am picking up an old lua project and maybe my memory tricking me and nothing changed in this regard. Anyway: i used SetTrackUIVolume() as you suggested instead of reaper.CSurf_OnVolumeChange() but the behaviour is the same. The curious thing is that if track is in write mode both SetTrackUIVolume() and reaper.CSurf_OnVolumeChange() apparently work as expected. This just happens with touch mode as far as i know. The curious thing is that with reaper.CSurf_OnSendVolumeChange() it also works fine in touch mode. So I assume something wrong specifically with volume touch(writting) functions.

The behaviour is that it doesn't replace old automation and instead it kind of merges with existing automation.

be sure to set done=false for SetTrackUIVolume(). But the script should also keep calling this while the user has the control touched (keeping the touch state set), and then call it with done=true when they release it (clearing the touch state).

the CSurf_*() APIs are designed to be used from a csurf plug-in, which also has the ability to set the touch state directly.

[Justin]

Originally Posted by mschnell

To me these automation modes plus the (automatic ?) selecting or copying Volume and/or Trim curves as target and/or source is rather confusing (OK, I should read the Guide ). (I normally don't do more than draw Volume curves by Mouse, but when I added a Control Surface Device to my setup by CSI, those things got confusing and not really usable. Even more so, as Volume wants to be controlled by Motor Faders, who feature touch sensitivity, and pan wants to be controlled by rotaries with LED ring, who dont.)

When it now comes to automating the automation by scripting it seems likely that the confusion grows - be there any Reaper glitches or not .

If there are touch-related bugs in CSI let Geoff know this, it's likely fixable on his end.


I'll do some tests with the built-in MCU/FaderPort modes to make sure it works properly too.

[deeb]

Originally Posted by Justin

be sure to set done=false for SetTrackUIVolume(). But the script should also keep calling this while the user has the control touched (keeping the touch state set), and then call it with done=true when they release it (clearing the touch state).

the CSurf_*() APIs are designed to be used from a csurf plug-in, which also has the ability to set the touch state directly.

You are absolutely right. This works as you described in my immediate testing. Thank you very much.

[deeb]

For your information writing FX parameters are recording ahead of play cursor. (at least for me and my configuration world so maybe i am missing something)

[mschnell]

Originally Posted by Justin

If there are touch-related bugs in CSI let Geoff know this, it's likely fixable on his end.

What I see hard to work with is not a bug, but just the difference between touch sensitive vs not touch sensitive control elements: how should the not touch sensitive control elements work in "touch envelope recording mode" ? AFAIU, the touch sensitive control elements work by far best in "touch envelope recording mode", but for a single track, all envelopes are bound to use the same mode. (Need a FR ? I am not a heavy CS user, hence I did not push this forward, yet.)

[deeb]

Originally Posted by Justin

If there are touch-related bugs in CSI let Geoff know this, it's likely fixable on his end.

It's not a bug but an incoherency in a specific context. In Read mode External Plugins behaves differently then Native Fx plugins/Track parameters.

With Native plugins and track parameters we are stuck when there is automation envelope and in read mode because we can't preview/change the sound of a knob that we explicitely drag. This is undesired for many reasons.

In the next licecap notice that Gain (external plugin) takes control of the sound while being dragged and automation takes control back when released. Notice this does not happen when dragging the track parameter "volume". The knob does not control anything - volume is unchanged. All reaper plugins and track parameters work like this and is very unconvienient.

[mschnell]

With touch sensitive (hardware) controllers live is good:
"Touch write mode" obviously writes as long as touch is active.

"Read mode" essentially is (or should be ???) "touch read mode" and the parameter is only controlled by the envelope if the controller is not touched.
Unfortunately non-hardware controllers (e.g. on a plugin's GUI) don't provide a "touched" information to the DAW - as there even is no API definition for this, notwithstanding that mouse down on the control easily could be encoded for that. (Maybe some Reaper stock plugins do, nonetheless, in some propriety way).

I understand that the other envelope modes (and read mode with parameters without touch sensitivity) are provided exactly for that reason, but to me it's not really practical / usable.

[nofish]

Originally Posted by deeb

For your information writing FX parameters are recording ahead of play cursor. (at least for me and my configuration world so maybe i am missing something)

Just a guess but may be related to Anticipative FX processing (render ahead) setting?

edit:
And actually you should check if it's a regression to v7.22 when posting here.

[illsoulprod259]

Is the ability to recall the group names when importing templates being looked into while adding the 128 groups when grouping?

[EpicSounds]

Originally Posted by illsoulprod259

Is the ability to recall the group names when importing templates being looked into while adding the 128 groups when grouping?

are you saying they broke something?

[deeb]

Originally Posted by nofish

Just a guess but may be related to Anticipative FX processing (render ahead) setting?

just checked, yes it is related with Anticipative FX render ahead processing. My setting it is with default value, which is 200ms. I set it now to 0ms and looks fine, but not sure about the disadvantages. I wonder why it records automation ahead of time what we record in real time - is this really necessary? seems something is not quite right, but i don't know. I would like to take advantage of render ahead since apparently it can use cpu more efficiently but with this side effect it is not useful to me.

[Justin]

Originally Posted by illsoulprod259

Is the ability to recall the group names when importing templates being looked into while adding the 128 groups when grouping?

ah do you mean that the grouping window doesn't update in response to loading project templates? fixing that.

[PMan]

Sorry for being late to the party, but I just installed 7.23, loaded a project, and got this error:

I dropped back to 7.22 and the error went away.

[PMan]

Also, this script (Send Buddy) doesn't work
https://forum.cockos.com/showthread.php?t=291712

[creal]

Hello,

All is in the title. The new render window that displays info is great, but 4K monitors users still deserve some love.

[Justin]

Originally Posted by PMan

Sorry for being late to the party, but I just installed 7.23, loaded a project, and got this error:

I dropped back to 7.22 and the error went away.

Can you post the .rpp file? Or email it to support at cockos dot com, if you'd prefer not to make it public...

[PMan]

Sent!

[PMan]

7.24 does not have error I reported above, but it is acting *very* strange.
When I try to select a track in the TCP, it either doesn't select anything, or it selects the track below it. Clicking on buttons in the TCP seems to toggle other buttons in the track, but the correct track gets selected.
Double clicking a MIDI item does nothing if there is no MIDI item below it, or opens the MIDI item below in the MIDI editor.

It seems like everything is off by 1 in enumerated lists...

More test results to follow.

[PMan]

OK, so here is what's happening. The mouse position if off. In the gif, you can see how UI elements are highlighted - not when the cursor is *on* them, but when the cursor is above them.

I got the same behavior with the default theme.

Again, normal behavior in Reaper 7.22.

[Daodan]

Originally Posted by PMan

OK, so here is what's happening. The mouse position if off. In the gif, you can see how UI elements are highlighted - not when the cursor is *on* them, but when the cursor is above them.

I got the same behavior with the default theme.

Again, normal behavior in Reaper 7.22.

You should mention your OS I guess

[Justin]

Originally Posted by PMan

OK, so here is what's happening. The mouse position if off. In the gif, you can see how UI elements are highlighted - not when the cursor is *on* them, but when the cursor is above them.

I got the same behavior with the default theme.

Again, normal behavior in Reaper 7.22.

What window manager/desktop environment? Wayland or X11?

[PMan]

Gnome/Wayland.

I just tested with x11, same behavior.

I should add: this only happens in 7.24 - *not* in 7.23

[zaibuyidao]

I have tested the issue I previously reported regarding errors when using "Write edited metadata to media" and can confirm that it has been resolved in the latest version.

Thank you, Justin, for your efforts in resolving this issue.