v6.78+dev0324 - March 24 2023

[Vagelis]

v6.78+dev0324 - March 24 2023

• * Includes feature branch: configurable naming for in-project MIDI items
• * Includes feature branch: updated Windows manifest for newer OS features
• * Includes feature branch: always running non-bypassed FX when the UI is visible
• * Includes feature branch: crossfade new recording with existing media items if configured
• * Includes feature branch: video from background projects
• * Includes feature branch: FX containers
• * Includes feature branch: improvements to aligning takes after recording
• * Includes feature branch: arrange view override mouse modifier sections
• * Includes feature branch: toolbar armed/special animations
• * Includes feature branch: pooled and unpooled ARA edits
• * Includes feature branch: fixed lane comping
• * Includes feature branch: shortcut import/export improvements and multiple main keyboard sections
• * Includes feature branch: preview item selection for grouped tracks
• * Includes feature branch: GR metering as embedded UI for third-party VSTs
• * Includes feature branch: media item fixed lanes
• + Hardware outputs: improve quality when muting/unmuting tracks that have hardware outputs
• + Media explorer: add actions to edit metadata tags
• + Media item lanes: double-click unsynced comp area indicator to copy unsynced area to new lane and re-comp
• + Sends: apply mute fades to post-fader sends when muting/unmuting tracks
• + Super8: add optional per-channel fadeout of configurable loop-length multiple [t=275137]
• + Super8: avoid small glitch when stopping the last channel
• + Super8: fix quirky behavior when the same CC is used to record multiple channels [t=260223]
• + Super8: improve quality and performance of reverse function [p=2646530]
• + Super8: use linear fades when starting/stopping playback
• + Terminology: update various Pre-FX labels to be 'Pre-Fader (Pre-FX)'
• + Track record settings menu: separate output recording latency compensation option from channel modes
• # FX containers: fix duplicate menu displays
• # Media item lanes: don't adjust unsynced comp area edges when editing media item edges
• # Media item lanes: don't move edit cursor when changing comp area source lane
• # Media item lanes: fix comp area edges sometimes not moving with media item edges [p=2662258]
• # Media item lanes: prevent moving media items when switching comp source lane [p=2662258]
• # Sends: fix slight glitch with pre-fader sends surviving mute
• # Windows: update manifest to support Windows 8.1 features
• # macOS: fix menu items for custom actions/scripts/etc

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

[Vagelis]

[*]# Media item lanes: don't adjust unsynced comp area edges when editing media item edges

Yay, thanks a lot Schwa, now it's way more safe to edit in comping lane

But I still find a bit tedious to unsync an area so we could move it without the source, because it needs to move an item first to unsync.
Sometimes we just want to move the unsynced area without previously moving the item to unsync. Could there be a better way like to add to the right click menu an action to unsync, or with double click on the area in comping lane? (maybe should be added in double click context)

[Vagelis]

Also I guess the reports regarding RE and comp areas are not fixed in this pre.

[tonalstates]

Originally Posted by Vagelis

# Media item lanes: don't move edit cursor when changing comp area source lane

Thank you for that!

[schwa]

Originally Posted by Vagelis

Also I guess the reports regarding RE and comp areas are not fixed in this pre.

No, we haven't gotten around to polishing the razor edit interaction yet.

[ovnis]

bug: "offset overlapping media items" doesn't work.



- On a track where 2 items are overlaped with offset, I set the track on "fixed lane"

- I uncheck "fixed lane"
-> The 2 items are not offest anymore (bug).

[Vagelis]

Originally Posted by schwa

No, we haven't gotten around to polishing the razor edit interaction yet.

Ok! Overall the existing pre feels very very good so far <3

[benmiller]

Originally Posted by ovnis

bug: "offset overlapping media items" doesn't work.



- On a track where 2 items are overlaped with offset, I set the track on "fixed lane"

- I uncheck "fixed lane"
-> The 2 items are not offest anymore (bug).

i think that's to be expected as you lose info when switching out of fixed lane.

Fixed lanes are not really intended to be switched on and off too much. If you are in fixed lanes mode and make use of multiples lanes, then that track should stay in fixed lane mode.

[FeedTheCat]

Originally Posted by Vagelis

# Media item lanes: don't adjust unsynced comp area edges when editing media item edges

Perfect! I think this is the way to go

Don't know if there's an elegant solution, but there are 2 situations where this creates unwanted gaps when interacting with synced areas.

1. When you grab 2 items edges at once (1 unsynced/ 1 synced)
2. When you crossfade an unsynced area into a synced area.



Not the biggest of deals, as you can get the desired behavior by:

1. Grabbing the comp areas directly
2. Doing it the other way round (crossfade synced into unsynced).

Just thought I'd post in case there's a sensical way to avoid them.

[FeedTheCat]

Originally Posted by Vagelis

Ok! Overall the existing pre feels very very good so far <3

My thoughts exactly. Thanks schwa!

[ferropop]

1. When cleaning up bits, especially little slices created from auto comping punches, [i]the comp areas sticking around and not trimming is a bit odd.

2. In the above trim, it desyncs which again doesn't seem like it should.

[ferropop]

Should Razors in the Comp Lane operate on Comp Areas also, when Comping Mode is on?

[bolgwrad]

That's made my day, thanks!

[benmiller]

Originally Posted by ferropop

1. When cleaning up bits, especially little slices created from auto comping punches, [i]the comp areas sticking around and not trimming is a bit odd.

2. In the above trim, it desyncs which again doesn't seem like it should.

Well if the comp area dosen't get trimmed then it makes sense that the area gets desynced because the content in that area is not the same anymore on the comp lane and source lane.

My impression is that all razor actions should affect the items and the area.
it should affect the areas so you can copy paste a whole chunk of lanes and the associated comp areas. And for consistency, if one razor action affects the comp areas, then all razor actions should affect the comp areas (when comping is on of course, and not when it's off...)

[ferropop]

Originally Posted by benmiller

Well if the comp area dosen't get trimmed then it makes sense that the area gets desynced because the content in that area is not the same anymore on the comp lane and source lane.

My impression is that all razor actions should affect the items and the area.
it should affect the areas so you can copy paste a whole chunk of lanes and the associated comp areas. And for consistency, if one razor action affects the comp areas, then all razor actions should affect the comp areas (when comping is on of course, and not when it's off...)

I agree, in the comp lane specifically I think Razor deletes should operate on media and the comp area, and that a trim like the above should not desync.

...but I can think of many situations where the above isn't desirable. The mix of Comp Areas and Media Items and the multitude of interactions is just so tough to make everyone happy with.

[Regisfofo]

Thanks for the super8 fade addition !

[dub3000]

fxpansion VSTs are still fine with the win8.1 manifest, btw

[ferropop]

There's still some kind of buffering/gap happening during playback on Fixed Lane tracks. It takes a split second (or more) for the audio to kick in. What would be helpful in diagnosing?

[Justin]

Originally Posted by dub3000

fxpansion VSTs are still fine with the win8.1 manifest, btw

yay thx

[ferropop]

Justin/schwa - sorry this pertains to a few pres back but I can't find the specific thread.

The new Alt-Click Solo (the version that doesn't play the track's sends)... which action is this assigned to? I can only find this behaviour through the mouse click.

[Thonex]

Narrow Comped lanes can be hard to discern:

Maybe there should be a bright outline of the swiped narrow lanes to help keep track of comp areas?

Here is with narrow lanes mode (Swipe + Edit) -- it's kind of hard to see what is going on:



Here is Swpe mode only, it's much easier to see what is going on:

[Vagelis]

Good day to all, found a bug with fades on items in fixed lanes, when moving them in edit mode it unsyncs the area in comping lane.

[FeedTheCat]

Here's a weird inconsistency:

The resulting change to the fades of the synced area is the same, but you get a different behavior based on the type of edit that caused it:

[schwa]

Originally Posted by ferropop

There's still some kind of buffering/gap happening during playback on Fixed Lane tracks. It takes a split second (or more) for the audio to kick in. What would be helpful in diagnosing?

Can you post a screenshot of your Audio/Buffering settings?

By default REAPER buffers 1200ms of media so it's ready for playback. When making some kinds of edits, the buffer is intentionally cleared so you can hear your changes sooner. I'm not sure whether what you're hearing is the buffer being cleared when it doesn't need to be, or the buffer not being cleared when it should be. Are you getting a delay on initial playback, or after certain kinds of edits, or... ?

[Vagelis]

Originally Posted by Thonex

Narrow Comped lanes can be hard to discern:

Maybe there should be a bright outline of the swiped narrow lanes to help keep track of comp areas?

Isn't this possible by changing the fixed area outline from theme tweaker?
Also maybe it would be nice when there are no areas in editing mode, to show an outline at the bottom of the items in order to know where swipe drag is possible? (Or as an option maybe to test how it looks)

EDIT: Even though it's nice as it is now especially when moving the items freely anywhere.

[Aikido123]

As of at least the last two DEV releases (323 and 324) MIDI Step Input is not working for me. F1-F12 input does work, but not from the keyboard. Switching back to the last full release (678) it does work - everything else being equal.

[Justin]

Originally Posted by Aikido123

As of at least the last two DEV releases (323 and 324) MIDI Step Input is not working for me. F1-F12 input does work, but not from the keyboard. Switching back to the last full release (678) it does work - everything else being equal.

thanks, will look into this!

[Mercado_Negro]

+ Sends: apply mute fades to post-fader sends when muting/unmuting tracks

Thanks for this!

[FeedTheCat]

Was thinking about this potential simplification lately:

From a user perspective, what is the difference between an unsynced comp area and no comp area?

• You can see unsynced areas and you can switch by single click.
• You can't see non-existing areas but you can switch by double click.

So what if we made the entire comp lane look like a large unsynced comp area by default?

(synced areas in this mockup are green)



You can split this large area wherever you want. When a comp area unsyncs it leaves behind split points. You would never get gaps between areas, just split points.

What do you guys think? Does it make sense? Would it simplify or complicate things?

I'm not 100% convinced btw, just an interesting thought imo.

[lexaproductions]

Originally Posted by vitalker

[*]+ Sends: add options to have sends, hardware outputs unaffected by mute/solo[/list]

Can somebody tell me how to revert this? I tried to click/unclick the item in the preferences but now when I solo a track, my sends (to the loopback bus) are always on.

[Justin]

Originally Posted by lexaproductions

Can somebody tell me how to revert this? I tried to click/unclick the item in the preferences but now when I solo a track, my sends (to the loopback bus) are always on.

If you have a configuration that behaves differently than 6.78 with those options not enabled, post a minimal .rpp, thanks!

[Vagelis]

Bug? when the item loops the area goes out of sync.

[Vagelis]

Originally Posted by FeedTheCat

Was thinking about this potential simplification lately:

From a user perspective, what is the difference between an unsynced comp area and no comp area?

• You can see unsynced areas and you can switch by single click.
• You can't see non-existing areas but you can switch by double click.

So what if we made the entire comp lane look like a large unsynced comp area by default?

(synced areas in this mockup are green)



You can split this large area wherever you want. When a comp area unsyncs it leaves behind split points. You would never get gaps between areas, just split points.

What do you guys think? Does it make sense? Would it simplify or complicate things?

I'm not 100% convinced btw, just an interesting thought imo.

Gaps are necessary sometimes imo, especially when we want to move an unsynced area to a place where we removed an area previously. I think now it's safe like this because it's pretty clear where the synced comp areas are and we can't mess it with unsynced areas easily while editing or comping accidentally above them.

[FeedTheCat]

Originally Posted by Vagelis

Bug? when the item loops the area goes out of sync.

It's not a bug per se (and not related to looping). I've actually been monitoring this edge case in previous dev versions.

Here's how it worked previously:



What happens now is that as soon as the area goes out of sync, the area stops moving along with the edge.

I think this behavior is fine for the most part, it does has some issues:

1. Once it unsyncs, you can't drag the edge back to resync.
2. The area unsyncs at a different point if you drag faster (or depending on snap)

I agree that the ideal behavior would be if the area stayed in sync like this:



But I can imagine this being tricky to implement...

[Vagelis]

Originally Posted by FeedTheCat

It's not a bug per se (and not related to looping). I've actually been monitoring this edge case in previous dev versions.

hmm, i think it does have to do with looping as well, this is noticable if i extend the area and then the item loops, or if I change the size of the item, glue it, extend the area and then the item edge where when it loops it unsyncs.
Probably because the source is not looping, but maybe there is a ways to stay in sync when this happens.

Originally Posted by FeedTheCat

1. Once it unsyncs, you can't drag the edge back to resync.

This is preferable behavior, previously items edges were messed with the rest unsynced comp areas.
But you can always drag the area to sync and not the item.

[FeedTheCat]

Originally Posted by Vagelis

hmm, i think it does have to do with looping as well, this is noticable if i extend the area and then the item loops, or if I change the size of the item, glue it, extend the area and then the item edge where when it loops it unsyncs.

When the content of a comp area is not exactly the same in both comp and source lane, it has to unsync, no?

Originally Posted by Vagelis

This is preferable behavior, previously items edges were messed with the rest unsynced comp areas.

Preferable to the previous behavior, yes. But in general, if you drag too far, you'd want to be able to drag it back to sync again (during the same drag that is).

[lexaproductions]

Originally Posted by Justin

If you have a configuration that behaves differently than 6.78 with those options not enabled, post a minimal .rpp, thanks!

Here it is

Step to reproduce:
1- Setup two project, One that's playing back to the Loopback Bus, One that's receiving the Loopback Bus Audio
2- Playback the Sender project
3- Soloing a track does not prevent the other track to send to the Loopback Bus Although it is soloed in the project.
4- Muting the other tracks will effectively mute them though.

I have the preferences set this way

[ferropop]

General thought :



Muted Fixed Lanes tracks are barely differentiated from non-muted ones. Yeah the item colors dim, but the Muted Comp Areas remaining the exact same tint gives an "I'm audible" vibe.

Just QOL stuff I thought I'd mention as it comes up.

[Vagelis]

Originally Posted by FeedTheCat

When the content of a comp area is not exactly the same in both comp and source lane, it has to unsync, no?

Yes but when looping it, the source still has the same size as the first looped section of the item. (not when dragging just the edge to extend) "Maybe" there's a clever way to stay in sync, otherwise is not a big deal I think.

Btw I found a bug because i remember looping with midi is kind of broken, so I tried with audio and this happened. First the area unsyncs, then moved it back to sync but it didn't, then moved the edge of the item and the area was synced even when the item was looping. After when i dragged the edge of the item the area extended and unsynced to the size of the item. So i guess something has to do with looping..

[FeedTheCat]

Originally Posted by Vagelis

Btw I found a bug

I can replicate this bug by placing the comp area slightly before the end of the item:



Wish this wasn't a bug, but just how it worked lol Maybe there's hope for the ideal behavior after all.