v7.27+dev1129 - November 29 2024

[sockmonkey72]

v7.27+dev1129 - November 29 2024

• * Includes feature branch: ripple edit when editing media item edges
• * Includes feature branch: MIDI item reconfiguration on effective timebase change
• * Includes feature branch: phase alignment dialog
• * Includes feature branch: per-lane ripple editing
• * Includes feature branch: auto-filter CC for MPE
• * Includes feature branch: graphical crossfade editor
• * Includes feature branch: MIDI editor CC point scaling
• * Includes feature branch: playback support for rendered files
• * Includes feature branch: automation timing and take FX fixes
• * Includes feature branch: take FX tail-length utilization
• * Includes feature branch: implode/explode support in batch converter
• * Includes feature branch: trim leading/trailing silence in batch converter
• * Includes feature branch: batch converter UI changes
• * Includes feature branch: trim leading/trailing silence when rendering
• * Includes feature branch: auto-bypass plug-ins with PDC when record armed
• + Media item properties: support entering take start in source in samples, if all selected items have the same sample rate
• + Ripple: fix ripple-all potentially affecting automation too early on non-edited tracks
• + Ripple: fix ripple-all potentially affecting automation too early on non-edited tracks [p=2825443]
• # Crossfade editor: fix display when stretch markers exist
• # MIDI: treat timebase of beats (position only) as normal for MIDI items, do not set them to fixed tempo in response
• # MIDI: when inserting multitrack midi to track that has timebase set and adding tracks, inherit track timebase
• # Phase aligner: more responsive auto-updating alignment calculation/display
• # Ripple: improve behavior when rippling media item right edge

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

[sockmonkey72]

• # MIDI: treat timebase of beats (position only) as normal for MIDI items, do not set them to fixed tempo in response
• # MIDI: when inserting multitrack midi to track that has timebase set and adding tracks, inherit track timebase

So this is how the FX Container people felt...

Thanks

[BPBaker]

Originally Posted by sockmonkey72

[*]+ Media item properties: support entering take start in source in samples, if all selected items have the same sample rate

Oh, would you be able to do this for H:M:S:F, too? I was just needing that in a video project and thinking about asking for it. :-)

[*]# Ripple: improve behavior when rippling media item right edge

I'm sure there'll be differing opinions and more discussion on this, but at first blush this seems to be working the way I expected it to, thanks!

[akademie]

Originally Posted by sockmonkey72

v7.27+dev1129 - November 29 2024

• + Media item properties: support entering take start in source in samples, if all selected items have the same sample rate

nice addition
and thanks for fast inclusion

[vicnest]

The top right menu changed and requires one click + one mouse movement + one click on the Audio Device Settings.
The old way requires only one effortless/mindless click on the top right region.
This change seems not being listed on the changelog history. Please add an option to vert back to old way please. Thank you

Borrowed from old post:
The top right information used to be one left click to [audio device closed], it's a quick neat feature to lift audio device for multiple programs with only one mouse click. (Not every time I want it to be closed, so the preference device close is not used)

I add a hotkey combination to setup and close audio device.

The new menu is cool, but could it be right click?
Options are good, the Monitoring FX is nearby.
Project Setting (Alt-Enter) was originally under File menu and it's good there.

[akademie]

^^^^^^ I also do ask for reverting to click open audiodevice prefs and right-click for the menu (as it is most natural Reaper way) or preference to set such behavior by user.
Thanks

Originally Posted by vicnest

The top right menu changed and requires one click + one mouse movement + one click on the Audio Device Settings.
The old way requires only one effortless/mindless click on the top right region.
This change seems not being listed on the changelog history. Please add an option to vert back to old way please. Thank you
<snip> ...

[Daodan]

Setting MIDI item timebase from default - Beats (p, l, r) to Time from Item itself vs inheritance from track gives different results. Unexpected.

First I change timebase on top item to Time. Then I change timebase on track 2 to Time. Then change project tempo. From user perspective both items should behave the same because both set to Time now, doesn't matter that from different levels (item/track/project).

[Daodan]

If we dream of badges/timebase indicators, then I dream/propose the following:
Project timebase - Indicator on Transport panel - options: hide/show
Track timebase - Indicator on tracks - options: hide/show/show only when not default
Item timebase - Indicator on items - options: hide/show/show only when not default

[_Stevie_]

Originally Posted by Daodan

If we dream of badges/timebase indicators, then I dream/propose the following:
Project timebase - Indicator on Transport panel - options: hide/show
Track timebase - Indicator on tracks - options: hide/show/show only when not default
Item timebase - Indicator on items - options: hide/show/show only when not default

Absolutely this! This would help so much.

[slip_right]

When Ripple editing is enabled for all tracks, and Ripple edit when editing media item edges is enabled:

If a media item(1) out edge is dragged to left (to shorten the media item length), media items with in points after the media item(1) end point are rippled left as expected. Items that have in points before media item(1) out have their own out edge adjusted in relation to the media item(1) out edge. I would expect this item to be ignored by ripple rather than it be changed in time length too?

[slip_right]

Ripple left/right from Crossfade Editor seems to be broken in this release?

[slip_right]

An option to have text displayed for recording pass counter to be left or right justified rather than centre justified to avoid the value for $recpass jumping around the Big Clock window when the text changes from Next to Current would be nice please. It might be the case that we have other windows open hiding the majority of the Big Clock but would like to see the $recpass value only so it not jumping around would be helpful.

[chmaha]

Originally Posted by slip_right

Ripple left/right from Crossfade Editor seems to be broken in this release?

Working for me...

[cool]

Thanks for the Phase Aligner!
Some text is displayed in black, hard to read on a dark background:

[vsthem]

Originally Posted by Daodan

Setting MIDI item timebase from default - Beats (p, l, r) to Time from Item itself vs inheritance from track gives different results. Unexpected.

First I change timebase on top item to Time. Then I change timebase on track 2 to Time. Then change project tempo. From user perspective both items should behave the same because both set to Time now, doesn't matter that from different levels (item/track/project).

Is this a bug? I'm really hope this is not the expected behavior.

Really stoked that this is being worked on

[deeb]

Will this new tool/features will help to match/grid midi to a human tempo based recording?

[schwa]

Originally Posted by slip_right

When Ripple editing is enabled for all tracks, and Ripple edit when editing media item edges is enabled:

If a media item(1) out edge is dragged to left (to shorten the media item length), media items with in points after the media item(1) end point are rippled left as expected. Items that have in points before media item(1) out have their own out edge adjusted in relation to the media item(1) out edge. I would expect this item to be ignored by ripple rather than it be changed in time length too?

If I am understanding correctly, your question is about whether the blue item here should have its right edge edited or not, if ripple-all and ripple-edge is enabled?

[daxliniere]

Envelope point selection methods are no longer aligned. For example, let's take an envelope with 4 points on it.

1) Click on one env pt, hold CTRL, click on any other = pts can be selected and de-selected by clicking on them (CORRECT)

2) Click on first point, hold SHIFT, click on the last point = same behaviour as holding CTRL (INCORRECT: should select the range)

3) Use right-drag (marquis) to select a point, hold CTRL and drag over that same point = you can select and de-select individual points (CORRECT)

4) Perform same as 3 above, but hold SHIFT instead of CTRL = you can select, but not de-select individual points. (INCORRECT, behaviour should be the same as CTRL or SHIFT+marquis should be ignored altogether)

[slip_right]

Yes, thanks for doing the screen illustration. I would expect the blue item length to remain unchanged.

Originally Posted by schwa

If I am understanding correctly, your question is about whether the blue item here should have its right edge edited or not, if ripple-all and ripple-edge is enabled?

[schwa]

Originally Posted by slip_right

Yes, thanks for doing the screen illustration. I would expect the blue item length to remain unchanged.

If the project is set to ripple all tracks, and ripple when editing media item edges, then it is intended that the blue item right edge would move. The user is editing the right edge of the yellow item, so every left or right edge to the right of that time position should ripple along with the edit.

In this scenario, if any of the colored item right edges move, they should all move, I think. And if the colored item right edges didn't move, but the items on the right side of the screen did move, then all of those crossfades would get messed up.

[BPBaker]

Originally Posted by schwa

If the project is set to ripple all tracks, and ripple when editing media item edges, then it is intended that the blue item right edge would move. The user is editing the right edge of the yellow item, so every left or right edge to the right of that time position should ripple along with the edit.

FWIW My initial instinct was that blue item should not to move, too--or at least not move until the right edge of the yellow item passes the right edge of the blue item.



Might "catching" right items edges like this make sense? (Trying to think through what problems this might cause...)

Originally Posted by schwa

In this scenario, if any of the colored item right edges move, they should all move, I think. And if the colored item right edges didn't move, but the items on the right side of the screen did move, then all of those crossfades would get messed up.

If the rule is:
- Any non-selected items with left edge positions to the left of the selected+adjusted item's right edge will not have their own right edges adjusted unless/until the right edge of the selected+adjusted item is equal to the right edges of the non-selected items, after which they share the same right edge position.

In which case...

Originally Posted by schwa

...if the colored item right edges didn't move, but the items on the right side of the screen did move, then all of those crossfades would get messed up.

...yes, the crossfades would get messed up and have to be re-adjusted separately. But I think that might be expected/preferable in the situations I'm imagining. For instance, the screencap you provided might be something like this in my line of work:



In this case, I think I'd rather preserve the edge positions and arrangement of the green and yellow items while fine-tuning the right edges of the grey and purple tracks, accepting that the green/yellow items make need to be moved back into proper position to align with the right-most grey items in the image. (I *think*...)

EDIT: Darn, now I'm seeing how the right-most grey items would get out of alignment with my proposal... Hmm... Leaving this all here in case the thought experiment is useful! Perhaps @schwa's first option is better, and I would just lock the green/yellow items...

[AZpercussion]

Originally Posted by schwa

Looks good for me!

[Etc.etera]

Originally Posted by schwa

I do feel as though this behaviour breaks from other standard behaviours in Reaper. There are indeed catch-up movements and relative edge edits, but they only ever operate on the selected media items.

My expectation for this scenario would be that only downstream grey items would be moved by Ripple. The coloured, overlapping media items would be left untouched unless they were also selected, in which case perhaps it defers to the mouse modifiers weather there is a catch-up mechanism or a relative edge edit mechanism.

I would rationalise this by saying that unlike moving media items, when you're extending the item edge you're introducing new / different portions of source audio into the project, and doing this on all overlapping items could have some weird side effects which are duifficult to work around. Going the other way might mean you have to select a bunch of items before trimming, but there are fewer ways of it going wrong.

[Etc.etera]

Originally Posted by sockmonkey72

v7.27+dev1129 - November 29 2024
[*]+ Ripple: fix ripple-all potentially affecting automation too early on non-edited tracks [p=2825443]

Thanks for putting some attention on this, although it seems to have stopped automation on other tracks being moved all together. Here's an example for what I'm hoping for.

When Item 1 is moved I would expect all items and all automation to move, because all items are downstream of Item 1.

When Item 3 is moved, all automation under item 1 should remain in place, because Item 1 will not be moved.
The next two points on Track 1 should also stay in place, because there is no media item being moved however there might be other audio being generated from plugins or instruments which we want to remain as-is.
An edge point should be added at the start of item 2, and all subsequent points on track 1 to be moved.

[deeb]

Originally Posted by Etc.etera

My expectation for this scenario would be that only downstream grey items would be moved by Ripple. The coloured, overlapping media items would be left untouched unless they were also selected.

exactly! I did not say anything about ripple because i never use it, but i don't see any benefit adding "reaper smartness/hassles" instead of only do what we ask reaper to do with what we selected. I don't like magic things because we loose control and intuitiveness - otherwise reaper follows reapers view and not user view. Please Do as much as possible whatever we ask to do with what is selected and leave intact everything else. User do the logic by selecting things and do things on what is selected. Otherwise is not unintuitive, users view is too complex and different to be guessed by reaper. Reaper job is to do what we ask to do with what is selected and not trying to guess what user wants, because that is too much unpreditable/complex to be guessed by reaper. Please fix this also in non ripple editing. It feels like a bug.

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


edit: ofcourse is acceptable and welcome reaper trying to give some options for some predictable workflows, but they should be like that: options and not a native / default behaviour. What we select and what we do with what is selected is the foundation for interpreting users will in any context and this should be working flawlessly. Anything else might be a nice addon but never ever by compromising initial premisse.

[Justin]

Originally Posted by vicnest

The top right menu changed and requires one click + one mouse movement + one click on the Audio Device Settings.
The old way requires only one effortless/mindless click on the top right region.
This change seems not being listed on the changelog history. Please add an option to vert back to old way please. Thank you

Borrowed from old post:
The top right information used to be one left click to [audio device closed], it's a quick neat feature to lift audio device for multiple programs with only one mouse click. (Not every time I want it to be closed, so the preference device close is not used)

I add a hotkey combination to setup and close audio device.

The new menu is cool, but could it be right click?
Options are good, the Monitoring FX is nearby.
Project Setting (Alt-Enter) was originally under File menu and it's good there.

Hmm perhaps we'll make it show the menu on click if a script has requested a message there, otherwise have it use the old behavior.

The new menu is cool, but could it be right click?

Funny thing, the menu is not new! It's been there via right click forever. But normally one doesn't right click menus. So you missed it, naturally.