v7.0pre12 - August 26 2023

[Vagelis]

Originally Posted by FeedTheCat

I guess collapsing could also be allowed when multiple lanes are soloed, but switching just wouldn't affect solo state.

If all lanes are soloed how to know in which lane to collapse? I think it works nice as it is now, but maybe it would be nice too if could remember the previous state before collapsing.

Originally Posted by schwa

You can shift-click or right-click the lane expand button to collapse/expand lanes.

I know but collapsing is something used more often than expanding, previously it felt pretty nice to collapse with a single click without using a modifier for such a basic feature.
Whether using the menu to switch from small to big lanes feels ok and I think we're not going to switch these behaviors that often after being defined.

[DerTonmeister]

We have "turn off comping". Can we have "turn on comping", too to comp to the last selected selected comp lane?

[Sexan]

Originally Posted by Vagelis

I know but collapsing is something used more often than expanding

Yes

[FeedTheCat]

Originally Posted by Gass n Klang

Don't know if I'm the only one but I don't wanna use small lanes at all. With just a handful of takes you cannot see anything anyway. So I'd like to have a toggle: "show only one lane - big lanes".

I also don't think I'll use it much. Afaict it's only useful for tracks with multiple soloed lanes where "show only one lane" doesn't work. Otherwise "show only one lane" is always preferable, no?

Maybe if we allowed "show only one lane" on layer tracks (e.g. it would collapse to the last soloed lane), we wouldn't need small lanes at all.

[Vagelis]

Originally Posted by Gass n Klang

We have "turn off comping". Can we have "turn on comping", too to comp to the last selected selected comp lane?

Maybes this helps but you can double click on the lane button or choose comp into this lane.

[smandrap]

Originally Posted by Vagelis

This is intended I think and it's there for a long time. This is because when collapsing we can switch lanes from the arrows and listen one what a time, since it's collapsed. Except if you mean to remember the previous state?

Remembering the previous state would be nice for a start, but I feel this behavior is counterintuitive: if I Play all lanes (for layering) and then I click "show only one lane" why would the layering disappear?

In my opinion collapsing should be a visual thing only. When collapsed we should still be able to select lanes with the arrows, but if multiple lanes are playing and the lanes are collapsed, some sort of visual indicator is needed.

Don't know if I explained myself correctly (bad English sorry), but in the end I'd like to be able to layer stuff, play all lanes, and collapse the lanes to see just one of them.

[Sexan]

Problem with new collapse behavior is we are forced to used them all the time. If you want to zoom then you need big state but then minimum track size is big, but if you use small then you need to toggle other state to zoom. Unnecessary steps.
Also changing state while in some XY zoom level toggles different zoom level so everything jumps everywhere




pre9 had nicest behavior here

[DerTonmeister]

Originally Posted by FeedTheCat

I also don't think I'll use it much. Afaict it's only useful for tracks with multiple soloed lanes where "show only one lane" doesn't work. Otherwise "show only one lane" is always preferable, no?

Maybe if we allowed "show only one lane" on layer tracks (e.g. it would collapse to the last soloed lane), we wouldn't need small lanes at all.

yes right. When working with layers I don't think that small lanes are helpful. Perhaps we need them cause one lane won't work but I think small lanes isn't ideal for anything. If you stack multiple kick sounds for example, you normally want to work with the whole "package" for copy / paste usage. With small lanes even that is fiddly

[DerTonmeister]

Originally Posted by Vagelis

Maybes this helps but you can double click on the lane button or choose comp into this lane.

yeah sure, I think it's just a better workflow if you could click the same button (or even via action) to toggle between these two states.

[Vagelis]

Originally Posted by Gass n Klang

yes right. When working with layers I don't think that small lanes are helpful. Perhaps we need them cause one lane won't work but I think small lanes isn't ideal for anything. If you stack multiple kick sounds for example, you normally want to work with the whole "package" for copy / paste usage. With small lanes even that is fiddly

I'd love to keep them please, I still find small lanes useful and since it's an option it wouldn't harm anyone right?

Originally Posted by Gass n Klang

yeah sure, I think it's just a better workflow if you could click the same button (or even via action) to toggle between these two states.

This button is a toggle, if you double click it turns comping off, doing the same after it turns comping on.

[DerTonmeister]

Originally Posted by Vagelis

This button is a toggle, if you double click it turns comping off, doing the same after it turns comping on.

good to know thanks Thought that works just via rightclick atm (where "turn comping off" is greyed out instead of showing "turn comping on")

[ovnis]

Originally Posted by Gass n Klang

Yes, less horizontal space is very welcome!

When we work on little screens, TCP lenght is very important and if the width of the tcp is too large it can become really annoying.

Leave the choice to users to adjust the size of media item lanes section as they want (and not as you wish by imposing a minimum thickness). They are not morons incapable of doing things well.

You trust them to set the TCP width like they want so why not give them the freedom to adjust the size of media item lanes TCP as they want?!

Many of us are already asking for this...

Originally Posted by Gass n Klang

Don't know if I'm the only one but I don't wanna use small lanes at all. With just a handful of takes you cannot see anything anyway. So I'd like to have a toggle: "show only one lane - big lanes". Nevertheless I like the new position of the button as you can toggle without moving the mouse.

I only use small lanes and I zoom if I want to see them better. When we have lots of tracks (and/or a little screen), if the hight of media item lanes TCP (with media items lanes) is too high it can be very hard to navigate.

[DerTonmeister]

inconsistency: with edit-grouped tracks, the new triangle changes small/big lanes for all tracks, but shift clicking it just changes one instead of all group tracks to "show only one lane"

[Vagelis]

Originally Posted by Gass n Klang

good to know thanks Thought that works just via rightclick atm (where "turn comping off" is greyed out instead of showing "turn comping on")

It doesn't work with double click as I mentioned? If so what's your default left click modifier in "Fixed lane header button" context?

[DerTonmeister]

Originally Posted by ovnis

Leave the choice to users to adjust the size of media item lanes section as they want (and not as you wish by imposing a minimum thickness). They are not morons incapable of doing things well.

I just meant it's very welcome to save space.

[ovnis]

Originally Posted by Gass n Klang

I just meant it's very welcome to save space.

Yes I know. I was just supporting your point.

[Phazma]

Originally Posted by Mercado_Negro

[*]+ Scroll: change preference for 'vertical scroll step' to 'vertical scroll maximum step', because different control devices may scroll at different resolutions/speeds
[*]+ Zoom/scroll: consistently support small control device moves, such as from a trackpad or trackball

I first got excited when I read these but OMG please revert whatever you have done or make it optional as it got way worse! Vertical scroll got way more stepped when zoomed in, even setting a scroll step as low as 10% doesn't help anymore which it did before to some degree. When zoomed out it still scrolls very slowly as before. It seems like you have done the opposite of what was needed and made the steps bigger when zoomed in while keeping them small when zoomed out instead of the other way around making the steps smaller when zoomed in and bigger when zoomed out.

I wish people using non-stepped control devices could have a scroll that looks as high-res as hand scroll. Or maybe an action that allows to map hand scroll to mousewheel/MIDI CC? But if not, at least return it to how it was before.

Is it clear what I am trying to say? Would it help if I provide some screen recordings? I bet you don't have a Macbook or Apple trackpad/mouse to test these behaviors? I'd be very happy to help test this and get it right but it's a bit hard for me to explain what I am seeing and how exactly it should change.

EDIT:

It's also noticable at 10% scroll step size that macOS inertial scrolling (the behavior that is enabled when unchecking the throttle mouse-events checkboxes) isn't supported properly. The scrolling does accelerate but only up to a certain point and then remains at a fixed pace for a few seconds and then decelerates again. It should acellerate more and after reaching the maximum start decelerating in a more linear manner.

[DerTonmeister]

Originally Posted by Vagelis

It doesn't work with double click as I mentioned? If so what's your default left click modifier in "Fixed lane header button" context?

it does work as you say. As I didn't know before, I did it via context menu. I thought it just would be nice to have the toggle option there, too. Atm you just can turn comping off via context menu. But well, doubleclick is great, so thanks for that hint!

[DerTonmeister]

Originally Posted by Phazma

Is it clear what I am trying to say? Would it help if I provide some screen recordings? I bet you don't have a Macbook or Apple trackpad/mouse to test these behaviors? I'd be very happy to help test this and get it right but it's a bit hard for me to explain what I am seeing and how exactly it should change.

yes. I wished, the scroll behaviour was just like it is in finder, chrome or anything else.

[Vagelis]

Originally Posted by Gass n Klang

it does work as you say. As I didn't know before, I did it via context menu. I thought it just would be nice to have the toggle option there, too. Atm you just can turn comping off via context menu. But well, doubleclick is great, so thanks for that hint!

Ah ok now I got it, instead of turning comping off from the menu you could use comp into this lane for the same behavior, then toggle only comp into this lane for on/off.
But I think it's faster with double click, cheers

[DerTonmeister]

Originally Posted by ovnis

I only use small lanes and I zoom if I want to see them better. When we have lots of tracks (and/or a little screen), if the hight of media item lanes TCP (with media items lanes) is too high it can be very hard to navigate.

As we now thankfully have a two-way setting for folder tracks (which I set to normal - hidden) I'd love to have the same for lanes. I'd love to automatically have each lane at the previous track height so items don't get bigger or smaller in comparison to their "show only one lane" size.

[bFooz]

Includes feature branch: optionally hide collapsed tracks within a folder

Since this is in developement, a FR: an option to link TCP folder/children visibility with MCP.

And it would be great if the whole height status in the TCP was mirrored in MCP. E.g. the collapsed children would make MCP tracks similarly collapsed, the same with hiding, with normal and small.

[Phazma]

Originally Posted by Gass n Klang

yes. I wished, the scroll behaviour was just like it is in finder, chrome or anything else.

Exactly. I am trying to explain it, show it, promote it, bring it to the dev's awareness etc. since years, but for some reason this keeps being ignored or not done correctly and I don't get how most macOS apps (not only by Apple) work like this as if it was the most normal thing and Reaper just doesn't. If this was something that required much testing and was so complicated to get right, way less apps would have it.

They implemented one significant improvement though some years ago, which made scrolling at least bearable. If you haven't already, go to Settings > General > Advanced UI/system tweaks and UNCHECK the three "Throttle mouse-events" boxes at the bottom. It's not yet finder-grade scrolling but much better than with those boxes checked.

[Vagelis]

Could we PLEASE have an improvement or an option with the modifier behavior move items with areas and adjacent area edges?

Could the most bottom items have priority instead of comping empty gaps? Like each time there's an empty gap without items, to pick the most bottom item for comping.
The behavior would be tremendously improved since now it's so difficult to manage this. Here's an idea:



It would be SOOOO useful if empty selections could be filled with the most bottom items...

[souk21]

Originally Posted by Phazma

Vertical scroll got way more stepped when zoomed in

Strange, I'm using mac+trackpad (with throttle off) and here scrolling over arrange feels similar to before.
On the other hand, scrolling over TCP/scrollbars is smoother with this version; in previous version the steps were huge (100% of track height AFAICT)

So yep, here scrolling over arrange is not worse than before, and scrolling over TCP/scrollbars is better; so for me it's a win

But I agree that the steps are still too big; the feel is not great.

[Vagelis]

Also comping the most bottom items with the modifier I mentioned previously, brings solution for comp areas to be restored, since even if it's passing through others to another location it will still be audible:
(Guessing that the adjacent comp area edges should follow the most bottom items)



This solves the biggest issues, we won't have to worry again about breaking comps or comp empty gaps, the whole workflow would be improved a lot! It's still the only thing I'm missing that's not there yet, IMHO.

[splitting_ears]

Originally Posted by Mercado_Negro

v7.0pre12 - August 26 2023

• + Scroll: change preference for 'vertical scroll step' to 'vertical scroll maximum step', because different control devices may scroll at different resolutions/speeds
• + Zoom/scroll: consistently support small control device moves, such as from a trackpad or trackball

The "vertical scroll maximum step" parameter doesn't seem to support values <10%. Nice improvement though!

[FeedTheCat]

Originally Posted by Mercado_Negro

+ Scroll: change preference for 'vertical scroll step' to 'vertical scroll maximum step', because different control devices may scroll at different resolutions/speeds

Hmmm, could "Vertical scroll maximum step" maybe allow numbers over 100%? Then we could script ourselves a solution that adjusts the scroll step based on how many tracks are visible. With a scroll step over 100% it would be possible to make scrolling faster when tracks/lanes are at minimum height.

[DerTonmeister]

Would be nice if the lane names could be longer than 2 characters.

[FeedTheCat]

Originally Posted by Gass n Klang

Would be nice if the lane names could be longer than 2 characters.

[Vagelis]

It would be nice too if we could hide lanes and restore them from the header menu. Especially helpful when working with many comp lanes to save space or work with one at a time, or to hide finished edits or comps that we don't want to edit or comp with the rest.

[Meo-Ada Mespotine]

Regarding raw-rendering:
How do I get/set the "Write .rsrc.txt sidecar file"-checkbox via API?

It doesn't seem to be part of the renderstring, configvars or reaper.ini...

[deeb]

[Phazma]

Originally Posted by souk21

Strange, I'm using mac+trackpad (with throttle off) and here scrolling over arrange feels similar to before.
On the other hand, scrolling over TCP/scrollbars is smoother with this version; in previous version the steps were huge (100% of track height AFAICT)

So yep, here scrolling over arrange is not worse than before, and scrolling over TCP/scrollbars is better; so for me it's a win

But I agree that the steps are still too big; the feel is not great.

The difference in scrolling the arrange is most visible at a small step size like 10%. Here videos to compare the two at 10% step size:

This version (v7.0pre12): https://vimeo.com/858387608

Previous version (v7.0pre11): https://vimeo.com/858387312

I should mention that I am scrolling with a custom action that includes two 0.5x modifier actions before the actual scrolling action.

As you can see, in pre11 the scrolling looks pretty good already at this specific zoom size (albeit it takes me pretty strong swipes to scroll a not so large distance).
When zooming the tracks smaller than the size in the video, the scrolling gets slower and at minimum size it is painfully slow, making the 10% value unusable.
When zooming the tracks bigger than the size in the video, the scrolling gets more choppy and when increasing the scroll step size to a value higher than 10% it gets worse.

Pre12 doesn't improve and of these negative sides and instead makes the pretty good scrolling that pre11 had with 10% at the track size in my video worse.

The number of pixels that each scroll step scrolls should not increase with the zoom level.
This would allow, for the same amount of physical scrolling, to scroll more tracks when zoomed out and fewer tracks when zoomed in, always keeping the same perceived resolution.

[Justin]

Originally Posted by Meo-Ada Mespotine

Regarding raw-rendering:
How do I get/set the "Write .rsrc.txt sidecar file"-checkbox via API?

It doesn't seem to be part of the renderstring, configvars or reaper.ini...

hah oops, it's not saved correctly, fixing

[nepenthe]

+ FX: add menu item to move selected FX to container

Woo! Thanks devs

[souk21]

Originally Posted by Phazma

I should mention that I am scrolling with a custom action that includes two 0.5x modifier actions before the actual scrolling action.

I tried this with pre11 and pre12, and get the same behavior difference.

But I would argue that pre11 behavior is not ideal either:
Scrolling's kinda smooth when you're zoomed in, but it slows down to a crawl when you zoom out.
Pretty annoying trade-off, to be honest.

I think the real issue is:

Originally Posted by Phazma

The number of pixels that each scroll step scrolls should not increase with the zoom level.
This would allow, for the same amount of physical scrolling, to scroll more tracks when zoomed out and fewer tracks when zoomed in, always keeping the same perceived resolution.

Agreed! When I scroll I think in terms of how many pixels/screen space I want to move; not really in terms of track count or % of track height

[DerTonmeister]

Originally Posted by souk21

Scrolling's kinda smooth when you're zoomed in, but it slows down to a crawl when you zoom out.
Pretty annoying trade-off, to be honest.

yep, that's why track size shouldn't matter. There should be some kind of acceleration as it is in every other program. Best would be to just do the same the OS does so scrolling does exactly feel like browsing the web. I think that's the best way to satisfy everybody's expectations.

[AZpercussion]

Originally Posted by Vagelis

Could the most bottom items have priority instead of comping empty gaps?

Gaps are necessary for speech comping.

[Vagelis]

Originally Posted by AZpercussion

Gaps are necessary for speech comping.

There are so many ways to create gaps now, you can remove areas or use the modifier which moves the items with comp areas that does this, what I'm asking is a lot more useful and important for me than having gaps while re-arranging, explained this so many times extensively and it wouldn't harm any other wokrflow. (Talking about editing sources and not items in the comp lane)