v6.64+dev0714

[musicbynumbers]

v6.64+dev0714 - July 14 2022

• * Includes feature branch: track media/razor edit grouping
• * Includes feature branch: pan law/function improvements
• * Includes feature branch: improve experimental silent-track CPU reduction option to include FX tail length
• * Includes feature branch: media item fixed lanes
• * Includes feature branch: internal pin management overhaul for future extension
• + Grouping: enable "selecting item selects group" for all projects
• + Grouping: mouse-copy affects grouped items regardless of item selection (item grouping or track media edit grouping)
• + Razor edit: improve reassignment of item groups after split and delete in certain scenarios
• + Razor edits: preserve item grouping when cutting or deleting razor edits with ripple-all-tracks enabled
• + Track grouping: add preference (in Media Item Defaults) for media/razor edit grouping overlap requirement
• + Track grouping: mouse edits affect grouped items regardless of selection; actions affect selected items only (same behavior as item grouping)
• + Windows: improve alt-key behavior relating to menu activation and cursor updating
• # Track grouping: display grouping indicators in TCP rather than arrange view
• # Track grouping: display items as grouped even when selected
• # Track grouping: group items if at least half of either the leader or follower item overlaps the other
• # Track grouping: improve handling of actions when no items are selected [p=2576958]
• # Track grouping: simplify implementation to be more like item grouping
  

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

[schwa]

Fixed a couple of display bugs after the build was posted, these fixes will be in the next +dev build:

- Track grouping: respect preference to not display track grouping indicators
- Track grouping: update media/razor edit grouping display after changing display preference

[Sexan]

Nice update!

Still confused whats the logic here ?



Selected means you can cut it and green outline shows that item is in a same group? Why is everything moving while 2 small items are not selected but highlighted?

EDIT: This is one of the situations why I would like to have enclosed only without any overlap, not even sure if this is considered overlap or just the way leader is calculated

[schwa]

Originally Posted by Sexan

This is one of the situations why I would like to have enclosed only without any overlap

Ah... that's actually a result of "selecting one item selects group", which is disabled by default, but we forced it to be enabled for this build to identify cases where it is a problem, like this one for example!

[Mercado_Negro]

* Includes feature branch: improve experimental silent-track CPU reduction option to include FX tail length

Is this still on the cards to be included as a global option in the Project Bay?

[Klangfarben]

The customizable percentage is not a good solution. If anything, it is even MORE confusing. Here is an example where I have set the overlap to 10 percent. So right off the bat, there is confusion because apparently 100 percent = fully enclosed only. Whereas my expectation would be if I set it to 10 percent overlap it should be selecting an overlap of no more than 10 percent.



Now, in the next GIF I have the same grouped tracks and items and I've set the overlap to 80 percent. The only difference is that the selection of the 2nd item in track 5 doesn't select the track 4 item. Everything else selects the same even though the overlap percentage amount is wildly different. This is just way too confusing. I don't think any user is going to be able to make sense of this.



And in the next example, I have set it to 100 percent (apparently fully enclosed selection only). But it is selecting an item in track 6 that is obviously not fully enclosed by any of the other items as it is longer than any of them and can't be fully enclosed. Furthermore, in a lead/follow scenario (all tracks in the GIF are set to lead/follow) if I click on an item in track 3 for example, that track should now be the leader. But again, since the item in track 6 keeps getting selected as fully enclosed when it is not, the multiple lead/follow configuration doesn't seem to apply at all.



Letting the user set a percentage is not really much different than just setting it to an arbitrary number. The user is still not going to be able to eyeball it or understand why something is selecting and why something isn't. I know you might have a goal here other than WYSIWYG, but this is more like WYSIWTF. IMO the percentage "solution" is being lazy about this and should be thrown out the window.

[Kenny Gioia]

Originally Posted by Klangfarben

I know you might have a goal here other than WYSIWYG, but this is more like WYSIWTF. IMO the percentage "solution" is being lazy about this and should be thrown out the window.

Do you see a solution that would be most obvious to everyone?

[schwa]

Regardless of what the rules for grouping end up being, for the next build the track edit grouping will be applied transitively, meaning selecting any individual item in the group will result in the same set of items being grouped, which should help with predictability.

[Klangfarben]

Originally Posted by Kenny Gioia

Do you see a solution that would be most obvious to everyone?

Well, I think from a new user perspective, the only obvious solution would be either fully enclosed only or fully enclosed + overlap (any). So, if Schwa is opposed to any solution that is based on edit/mouse cursor (and I understand both of his concerns with that), then a checkbox with those two options in the prefs would probably be the most obvious to start with for the new user and then be able to override the overlap with a percentage amount.

The inconsistency I think is what is going to throw users here. Like in this current pre, selecting 100% overlap (i.e. fully enclosed) selects items that aren't actually fully enclosed (3rd GIF in my post above). And the examples Sexan posted where items that aren't selected (but have a green group outline) are moving. Or if unselected items split. Those kinds of things are going to be really confusing for everyday use.

The other issue with the percentage amount besides being difficult to make a visual determination of the amount of overlap (eyeballing it) is that there never is going to be a "one size fits all". It's going to change based on the material being edited. So if it does end up going that route, it is going to have to be changed pretty often, even within the same project. Which makes a global pref problematic. That's one scenario where edit/mouse cursor really helps, because the user can change the amount of overlap simply by moving the mouse/edit cursor rather than having to open the prefs and change a value.

Keep in mind, in a multiple lead/follow group scenario, where the user clicks is determining the leader track, so essentially it is already tracking vertical mouse clicks. I'm not sure tracking horizontal clicks or the edit cursor as well would be out of bounds here. I know we are kicking the tires on this and Schwa is experimenting with this as we go, but I just have a difficult time envisioning a scenario where just setting a percentage is going to be a suitable solution to users who are going to be using this heavily, and will be confusing to new uses who are going to have a very difficult time trying to determine what is being selected and what is not.

There are a few other things that I think would help simplify this to make the initial selection more obvious (and I agree that is what we should be going for here), but I didn't want to bring them up while this is early in the process. Also because they've been done in other DAWs and I didn't want to champion a "DAW X does this best" approach which we know where that path leads lol.

[Sexan]

Originally Posted by schwa

Regardless of what the rules for grouping end up being, for the next build the track edit grouping will be applied transitively, meaning selecting any individual item in the group will result in the same set of items being grouped, which should help with predictability.

Thank you, looking forward to this!

[Sexan]

Hidden tracks cut or delete

[Sexan]

hidden tracks razor actions - Shift + S (split works fine)

[Sexan]

hidden tracks resize

[ovnis]

Razor seems a little bit broken:

It should replace the item slice but...

[schwa]

Originally Posted by ovnis

Razor seems a little bit broken:

It should replace the item slice but...

Do you have "always trim content behind razor edits" disabled in the options menu?

[Sexan]

should this be possible?

[daxliniere]

Originally Posted by musicbynumbers

* Includes feature branch: track media/razor edit grouping

I could defintiely see this taking over from item grouping in my workflow, but I would need actions to add tracks to a group that work as quickly as CTRL+G/U for item grouping.

Because this system uses the Grouping Matrix system, it's obviously not going to be as simple as item grouping/ungrouping because there's the added step of needing to assign to a specific "grouping group".

I have a related custom action using [b]SWS/S&M: Set selected tracks to first unused group (default flags)[b], but this relies on default flags, whereas this would require different flags and I'm not willing to change my default flags as I use them regularly.
(The operation is select desired tracks, run action.)

Any thoughts on how to solve this going forward?

[ovnis]

Originally Posted by schwa

Do you have "always trim content behind razor edits" disabled in the options menu?

No. I have checked with a previous verion and razor worked as intended.

And on the gif, it works well if I put the pasted razor on the next item.

[schwa]

Can you share a very simple project that demonstrates the problem, and sorry but I think we will need your reaper.ini as well?

[Sexan]

Originally Posted by schwa

Do you have "always trim content behind razor edits" disabled in the options menu?

I can confirm this issue, trim behind is enabled





New empty project, midi item, 1 long note, nothing special done. Trim enabled/disabled same thing

Same thing with media items

EDIT: also confirming pre before works fine

[daxliniere]

Originally Posted by daxliniere

I could defintiely see this taking over from item grouping in my workflow...

Aaaactually, what would make this new feature really rocket-powered is if we could easily toggle item grouping and track media group separately.

We have the action Options: Toggle item grouping override, adding Options: Toggle track media grouping override would be the duck's nuts.

[Sexan]

volume knob double click to reset not working

[Kenny Gioia]

Originally Posted by Sexan

volume knob double click to reset not working

I don't think that ever did.

[Sexan]

Originally Posted by Kenny Gioia

I don't think that ever did.

Yeah it did not, but in group context it does not make sense that you can modify volume of all groups but cannot reset (since we are basically doing same operation on all items at once).

If you reset on only 1 item then open media properties and set to 0 its set relative, so you get everything mixed up. So there is no easy way to make them all 0. But next allowed it (thank you schwa)

[Kenny Gioia]

Originally Posted by Sexan

Yeah it did not, but in group context it does not make sense that you can modify volume of all groups but cannot reset (since we are basically doing same operation on all items at once).

If you reset on only 1 item then open media properties and set to 0 its set relative, so you get everything mixed up. So there is no easy way to make them all 0. But next allowed it (thank you schwa)

I was just clarifying. I actually thought this was by design but I was wrong.

But I wanted you to know it's not a bug in the DEV.

[daxliniere]

Originally Posted by Kenny Gioia

I don't think that ever did.

That correct, it has never reset all items in a group, but I have always wished it would. I've needed to use scripts for this.