+ Free item positioning: allow editing FIPM height for multiple selected items at once
+ Free item positioning: allow editing FIPM position for multiple selected/grouped items at once
+ Group manager, Region manager: decrease margins for ease of use when docked
+ Group manager: suppress "automatically select tracks in group when selecting track" when adding/removing tracks from group via double-click on grouped track list cell
+ Grouping matrix: add option to show/hide flags in matrix
+ Grouping: allow edge editing of hidden grouped items
+ Grouping: consistent capitalization in grouping matrix labels
+ Grouping: create and edit track media/razor edit groups in grouping matrix or track group settings dialog
+ Grouping: don't open "grouping for selected tracks" dialog if no tracks are selected
+ Grouping: enable "selecting item selects group" for all projects
+ Grouping: enable "selecting one item selects group" by default for new projects
+ Grouping: fix grouped items deselecting on second click [p=2576299]
+ Grouping: fix media item deselection with regular item groups [p=2579153]
+ Grouping: increase size of media item group border
+ Grouping: media item edits on group-leader tracks will affect media items on all group-follower tracks, as if the media items were grouped
+ Grouping: mouse modifier to toggle item selection respects grouping when selecting or deselecting [t=259823]
+ Grouping: mouse-copy affects grouped items regardless of item selection (item grouping or track media edit grouping)
+ Grouping: razor edits on group-leader tracks will be mirrored on all group-follower tracks
+ Grouping: right-click in grouping matrix opens group settings dialog for already-selected tracks, rather than auto-selecting tracks
+ Grouping: support track media/razor edit groups, including leader/follower groups
+ Grouping: various razor edit behaviors apply to hidden grouped tracks
+ Grouping: when setting/unsetting free item positioning, also modify grouped tracks
+ Main toolbar: add grouping button context menu action to enable/disable track grouping
+ Master VU: fix RMS stereo loudness readout when RMS window length has been customized
+ Media explorer: fix possible noise at end of time selection playback [t=273221]
+ Media items: add preference to arrange overlapping media items in the order they were created [t=273275]
+ Media items: double-click to reset select item volume affects all selected items
+ Media items: mouse modifiers to adjust item contents and left or right edge affect all selected/grouped items with edges that align
+ Media items: mouse modifiers to edit item fade-in/fade-out with relative edge grouping only affects selected items, not grouped items (same behavior as item edge editing)
+ Mouse modifiers: add media item left-click modifier to toggle item selection ignoring grouping [t=259823]
+ Mouse modifiers: set default media item shift+alt (shift+opt) click behavior to create razor edit area
+ Razor edits: support razor edits on master track envelopes (except tempo envelope)
+ ReaScript: allow passing small integer values as KbdSectionInfo parameter to APIs as shorthand to access section by ID [p=2619501]
+ ReaScript: support GetSetTrackGroupMembership() with "MEDIA_EDIT_LEAD" and "MEDIA_EDIT_FOLLOW"
+ Region manager: when not displaying track dropdown list nested by folder, indent tracks in folders
+ Region/Marker Manager: fix display glitch when resizing
+ Render: fix minor memory leak after rendering
+ Routing/Grouping/Render matrix: dynamically adjust margins to fit text
+ Routing/grouping matrix: improve appearance of folder expand/collapse icons
+ Track group manager: add columns to show/hide groups in TCP and mixer
+ Track group manager: add option to add/remove child tracks when adding/removing folder track to group
+ Track grouping manager: add menu actions to add/remove selected tracks (note, action is incompatible with option to select tracks when selecting group)
+ Track grouping manager: add option to display track dropdown list nested by folders
+ Track grouping manager: fix checkbox appearance with dark themes on Windows
+ Track grouping: "selecting one item selects group" selects only enclosed media items on follower tracks
+ Track grouping: add Track Group Manager dialog
+ Track grouping: add actions to automatically group all tracks, or selected tracks, for media/razor editing
+ Track grouping: add actions to create track media/razor editing group from selected tracks, or remove selected tracks from group
+ Track grouping: add actions to enable/disable individual track groups
+ Track grouping: add buttons to track group settings dialog to open track group manager and grouping matrix
+ Track grouping: add menu actions to automatically group tracks for media/razor editing to main grouping toolbar context menu, TCP context menu
+ Track grouping: add preference (in Media Item Defaults) for media/razor edit grouping overlap requirement
+ Track grouping: add razor edit left-click mouse modifier to remove one area ignoring track grouping
+ Track grouping: add theme element for auto-grouped track indicators
+ Track grouping: improve grouping of razor edits on tracks with different numbers of fixed lanes
+ Track grouping: items behave as grouped if at least half of the item on the follower track overlaps the item on the leader track
+ Track grouping: mirror razor edit areas on envelopes to follower tracks
+ Track grouping: mouse edits affect grouped items regardless of selection; actions affect selected items only (same behavior as item grouping)
+ Track grouping: support customizing track group colors
+ Track grouping: temporarily ignore global preference to change track selection on arrange view click when automatic track grouping of selected tracks is enabled
+ Track manager/Track group manager: prevent re-sorting list while editing
+ Track manager: add column to display track group membership, double-click to open track group settings dialog
+ Track manager: add column to expand/collapse folders
+ Track manager: add option to show/hide/group child tracks when showing/hiding/grouping folder track
+ Track/Region/Group Managers: support setting items to random colors
+ Track/Region/Group managers: support resetting custom colors to default
+ Track/region/group managers: always select row on click
+ Track/region/group managers: only open dropdown lists and dialogs on double-click
+ Transport: use time signature when estimating tempo from time selection for tooltip
+ WAV: large file behavior for new users defaults to auto wav/RF64 rather than auto wav/wave64
# ARA: avoid further plugin code asserts when plugin does not support importing analysis [t=272818]
# Actions: deselect unaffected items on the not-selected side of the split when running action to split items selecting left or right [p=2578578]
# Actions: fix new action to split items respecting grouping, select left side [p=2576478]
# Grouping matrix: in detail view, display group name/ID consistently at start of group
# Grouping: fix selecting all lead/follow in track grouping dialog [p=2575988]
# Grouping: mouse modifiers that ripple contents earlier or later affect grouped items even if edges don't overlap
# Grouping: refresh item grouping indicators after moving media items [p=2576301]
# Media item fades: improve editing when using track groups [hp=2584958]
# Media item grouping: when running actions (like split, etc), items on follower tracks are affected if they overlap at all with items on the leader track
# Media items: use vertical space more efficiently when arranging overlapping media items in the order they were created
# Razor edits: cleaner display of razor edit areas on FIPM tracks when the area does not cover the entire vertical space
# Razor edits: fix save/load and undo/redo when using razor edits on master track
# Render: conditionally enable controls in Postprocess Render dialog
# Track group manager: add context menu option to select tracks when selecting group
# Track group manager: add context menu, docking support
# Track group manager: fix opening window on startup
# Track group manager: fix potential inconsistent row sorting
# Track group manager: when option enabled to set track selection from group selection, update track selection more quickly
# Track grouping manager: adjust radio buttons for dark themes on Windows
# Track grouping manager: fix enabling/disabling groups on selected rows [p=2584586]
# Track grouping manager: improve behavior when swipe-dragging below last group in list
# Track grouping manager: improve interaction between preference to select tracks when group selected, and grouping parameters dialog
# Track grouping: add actions to split item under mouse respecting grouping
# Track grouping: apply transitively (selecting any item in a group results in the same set of items being grouped)
# Track grouping: display grouping indicators in TCP rather than arrange view
# Track grouping: display items as grouped even when selected
# Track grouping: display track media/razor edit grouping indicators for automatic groups even if there are no other track groups defined [p=2586061]
# Track grouping: fix drag-copying grouped items
# Track grouping: fix multiple track selection when automatic grouping enabled and preference enabled to select track when clicking TCP controls
# Track grouping: for edge edits, grouped items are affected only if they overlap with the leader item at the start of the edit [p=2584208]
# Track grouping: group items if at least half of either the leader or follower item overlaps the other
# Track grouping: group items only if the leader item fully encloses the follower item
# Track grouping: handle mouse modifier to adjust item contents and right edge [p=2582906]
# Track grouping: if contiguous leader items are selected, consider them a single item when calculating followers
# Track grouping: improve behavior when grouping razor edits across tracks that have differing FIPM or fixed lane characteristics [p=2586276]
# Track grouping: improve grouping behavior when editing item edge
# Track grouping: improve handling of actions when no items are selected [p=2576958]
# Track grouping: item edits are grouped only if the item on a leader track encloses the item on a follower track
# Track grouping: media/razor edit grouping respects action to enable/disable all track grouping
# Track grouping: razor edits obey option to disable grouping
# Track grouping: razor edits on grouped tracks do not affect hidden envelopes
With this active its not possible to click on track areas of the arrange and change track selection/paste target track. Is this intended?
+ Track grouping: temporarily ignore global preference to change track selection on arrange view click when automatic track grouping of selected tracks is enabled
Otherwise, multiple track selection is always cleared when clicking on a media item, which defeats the preference to automatically group selected tracks for media item editing.
I think a lot of people will miss that they can double-click in some columns of the Track Group Manager for more options. Especially since they don't follow the rule of "right-click everything".
Can we get a hover tooltip or something ?
- Name - Double-click to rename
- Grouped Tracks List - Double-click for add/remove tracks menu
- Group Attributes - Double-click for track grouping parameters window
__________________
REAPER Video Tutorials, Tips & Tricks and more at The REAPER Blog
Is it intended that the options in mouse modifiers for "Select item" when set to a modifier like cntrl can't have the extra specifics for "ignoring snap" "move edit cursor" and "ignoring selection/grouping" added accumulatively? For actual modifiers, these replace each other on my system when added in mouse modifiers. (They do work together for plain select with no modifier)
Concerning GetActionShortcutDesc: there's a little issue with non-English layouts in regards to the special keys (Home/End/Delete/Insert/Page Up Down etc...). To cover all languages, it would be necessary to create a dictionary of ALL special keys in all languages. Couldn't the function just return the keycode + the modifier flag (shift, alt, ctrl, etc...) ?
For instance - if Space was pressed - the GetActionShortcutDesc function when passed in the commandid for Transport Play/Stop - would return keycode 32, and false for all the modifiers.
The script would then know that keycode 32 has been pressed - and that all the modifiers are false - so we can make a match with the return values for that commandid - and therefore know to trigger that commandid.
1. + Track grouping: add actions to automatically group all tracks, or selected tracks, for media/razor editing
We can't change track selection using default left click in track area in this mode. But we can without auto-grouping and whith auto-grouping all tracks. So, it's looks strange, why we need this limitation?
2. About the right click menu on grouping button in the main toolbar.
It seems that track grouping is about TCP controls and item grouping about arrange area. But track grouping affects item grouping too. Looks as a bug.
3. Selection and split bug
Middle item is not affected by selection and splitting, but obviously need to be.
There could be situation when I even will not know about fades or tails, they just will offscreen. Also, there could be many tracks, so not all will be visible and some unselected items can be lost.
If the user need to visually control all tracks and edit selection, what advantages of grouping?
I suggested in the past the way to find a follower for the leader item under mouse by comparison a leader candidates for each follower.
Which leader candidate crosses the follower more - that is the leader. And if it's that selected leader under mouse, the follower should be selected.
It's more complex than simple percantage comparison. It's still have lacoons in some cases, but most of the cases, which obvious for user himself, will processed right way.
Concerning GetActionShortcutDesc: there's a little issue with non-English layouts in regards to the special keys (Home/End/Delete/Insert/Page Up Down etc...). To cover all languages, it would be necessary to create a dictionary of ALL special keys in all languages. Couldn't the function just return the keycode + the modifier flag (shift, alt, ctrl, etc...) ?
For instance - if Space was pressed - the GetActionShortcutDesc function when passed in the commandid for Transport Play/Stop - would return keycode 32, and false for all the modifiers.
The script would then know that keycode 32 has been pressed - and that all the modifiers are false - so we can make a match with the return values for that commandid - and therefore know to trigger that commandid.
To add a little more context to this - this issue is regarding using this new API from a script - in order to trigger the appropriate actions in the main Reaper window.
FeedTheCat has created a very useful little script demonstrating this:
It scans through each action shortcut - and matches the desc value from this API function with the keys returned from gfx.getchar to find a match. When a match is found - we can use the commandid to trigger the action in the main window.
This allows a script to pass-through any key presses that are not used by the script to the main window - so these shortcuts remain active even if a script window has the focus.
The problem is - on Windows at least - matching the desc value is local language specific - meaning it's nearly impossible to cover all systems shortcut key descriptions. Eg. on UK keyboard - I get the page down button as PGDOWN. But on a German layout - we get BILD-NACH-UNTEN. So making a match relies on knowledge of the local language - which makes this a very non-elegant solution to the task.
But - if the API call could be modified (or an alternative one provided) to also return the keycode (as might be got from gfx.getchar) for the shortcut key - as well as boolean values for the modifier keys - shift, ctrl/opt, alt, then we can use these to match with the keyboard input to the script window and make this possible without having to maintain a list of different language shortcut key descriptions.
Grouped razor edit areas when drawn are only shown on mouse release.
That's slightly confusing / clunky IMHO
This was brought up by several users in the dev releases. It might have been a good idea to not put this on the shelf for so long and then simply releasing it with no changes for such a long period.
It's a bit of a catch-22. If the devs put it on the shelf, then users will stop giving feedback on it. If users stop giving feedback, then the devs will think it's justified to release without any further changes.
This was brought up by several users in the dev releases. It might have been a good idea to not put this on the shelf for so long and then simply releasing it with no changes for such a long period.
It's a bit of a catch-22. If the devs put it on the shelf, then users will stop giving feedback on it. If users stop giving feedback, then the devs will think it's justified to release without any further changes.
Just my worthless take on the matter...
I was one of the users that raised it in the earlier pres but I guess it's one of the minor things that didn't attract attention at that stage.
I was one of the users that raised it in the earlier pres but I guess it's one of the minor things that didn't attract attention at that stage.
As did a number of other things, which again is an argument for keeping development on it active before releasing (even if it's just minor tweaks) rather than putting it on the shelf. Especially for a feature this important.
Grouped razor edit areas when drawn are only shown on mouse release.
This was responded to during the prerelease cycle, although it was a while ago. We did some testing with drawing all of the grouped razor edits at once but it wasn't practical. It's very confusing when you have multiple razor edit areas being drawn at once away from the mouse, especially if you then drag the mouse over the automatically-created grouped razor edits.
Here I'm dragging the edges of three midi items on a tracks that are edit grouped (lead and follow).
When the double edge adjustment cursor is a few pixels to the same side as the drag direction the edit doesn't group.
This happens with the mouse modifier set to ignore grouping or not.
Also happens with audio items if there is no cross fade.
It's very confusing when you have multiple razor edit areas being drawn at once away from the mouse, especially if you then drag the mouse over the automatically-created grouped razor edits.
That looks eerily similar to a bug that has bedeviled me for 10 years but which has been hard for the devs to reproduce, and which apparently doesn't bother too many other people... lots of details and experimentation in this thread:
...maybe it's totally unrelated, but I thought I'd post the link in case it was related.
Quote:
Originally Posted by Triode
Here I'm dragging the edges of three midi items on a tracks that are edit grouped (lead and follow).
When the double edge adjustment cursor is a few pixels to the same side as the drag direction the edit doesn't group.
This happens with the mouse modifier set to ignore grouping or not.
Also happens with audio items if there is no cross fade.
Is it intended that the options in mouse modifiers for "Select item" when set to a modifier like cntrl can't have the extra specifics for "ignoring snap" "move edit cursor" and "ignoring selection/grouping" added accumulatively?
Here I'm dragging the edges of three midi items on a tracks that are edit grouped (lead and follow).
When the double edge adjustment cursor is a few pixels to the same side as the drag direction the edit doesn't group.
Here are some examples of potential complexity, and these examples are not even *that* complex. Having the grouped razor edits appear and disappear as the marquee is drawn would be too chaotic in many cases.
This was responded to during the prerelease cycle, although it was a while ago. We did some testing with drawing all of the grouped razor edits at once but it wasn't practical. It's very confusing when you have multiple razor edit areas being drawn at once away from the mouse, especially if you then drag the mouse over the automatically-created grouped razor edits.
For me it would be preferable to know/see what I am going to get before I release the mouse button, than to release the mouse button and then see what I got. But if this is technically difficult, then I am OK as it is. Very happy to finally get track-based grouping/editing!
Here are some examples of potential complexity, and these examples are not even *that* complex. Having the grouped razor edits appear and disappear as the marquee is drawn would be too chaotic in many cases.
Thanks for illustrating that.
I guess I use grouping pretty much exclusively for multi-miked instruments like drums and most edits I do are restricted to one instrument at a time rather than across overlapping groups. Looking at other DAWs like PT or that one that begins with an L, they show these kinds of selections on mouse down - but perhaps the ability to make multiple selections is more restricted.
I'll certainly be hoping for mouse down grouped razor view becoming a thing
Here are some examples of potential complexity, and these examples are not even *that* complex. Having the grouped razor edits appear and disappear as the marquee is drawn would be too chaotic in many cases.
Thanks, Schwa! That way we can see source selection and result selection separated and can analyse cause and effect relationships.
Here are some examples of potential complexity, and these examples are not even *that* complex. Having the grouped razor edits appear and disappear as the marquee is drawn would be too chaotic in many cases.
While this is an issue for selecting across groups, there is a pretty easy solution for this. For marquee and razor select, simply make the selection based on the current leader track. So for example, say you have a group of 4 tracks with track 1 as the leader. If a marquee select or razor edit select originates with the mouse in track one (leader), then show all 4 tracks/items in those tracks being selected. If the selection originates in a follow track, then it would only show that single track/track items being selected.
This would make the selection fairly easy because it only pertains to one group at a time and only if the selection originates in a leader track of that group, not a follower track. If you selected past the group, it would still just show selection of that group and not change when going past the group.
Quote:
Originally Posted by Triode
I guess I use grouping pretty much exclusively for multi-miked instruments like drums and most edits I do are restricted to one instrument at a time rather than across overlapping groups. Looking at other DAWs like PT or that one that begins with an L, they show these kinds of selections on mouse down
I agree with Triode. I think by far the most common use case here is single group editing at a time. In the case of marquee edits, if one selects tracks past the originating group, it still would be beneficial to see the selection of the entire group vs just a single track. I don't think there's anything unintuitive about showing the entire group selection on mouse down of a marquee select on a leader track and then if going past the bounds of the group leaving the mouse down selection as that group only until mouse release.
And if using razor edits, the same would apply. On mouse down on leader track, show group selection. If selecting past the group, razor edit selection is already pretty WYSIWYG so you still know what you are selecting past the group, so the changing selection on mouse up wouldn't be much different than what you are seeing while dragging. To me this is much less "blind" then having mouse down always be a single track selection, especially on marquee select. Again, the most common use case when editing groups is editing one group at a time as Triode points out.
While this is an issue for selecting across groups, there is a pretty easy solution for this. For marquee and razor select, simply make the selection based on the current leader track. So for example, say you have a group of 4 tracks with track 1 as the leader. If a marquee select or razor edit select originates with the mouse in track one (leader), then show all 4 tracks/items in those tracks being selected. If the selection originates in a follow track, then it would only show that single track/track items being selected.
Though currently we can set tracks as Media/Razor Edit lead and follow at the same time in the same group.
And tbh I quite like that, because then I can do a RE in any grouped track and be sure it's applied on all.
edit:
On further thought, these two things wouldn't necessarily exclude each other.
Your suggestion could still work when not having overlapping lead/follow tracks in a group.
Though currently we can set tracks as Media/Razor Edit lead and follow at the same time in the same group.
And tbh I quite like that, because then I can do a RE in any grouped track and be sure it's applied on all.
I think you are misunderstanding a bit. We are talking about the displayed selection on mouse down of the marquee/razor edit selection. Right now, mouse down only shows selection for one track and then changes on mouse up which is not intuitive.
So my proposed solution would not change the ability to select from tracks that are both lead and follow. The only thing it would change is the initial mouse down would select all tracks/track items in the group, based on leader tracks. If all group tracks were set to leader then marquee/razor selecting any of the tracks would select all tracks/track items in the group on mouse down. If only one or a few of the group tracks were set to leader, then it would select all tracks/track items in the group when the selection originates on one of the leader tracks.
I think you are misunderstanding a bit. We are talking about the displayed selection on mouse down of the marquee/razor edit selection.
Well, as I gather it, you talk about item selection and schwa in his post about drawing REA's (in fact I see no item selection there).
But may be that I misunderstood nonetheless, thanks for clarifying anyway.
So just to clarify in case I'm not making sense, here are some examples.
In the pic below we see a group of 4 tracks - track 1 is leader, tracks 2-4 are followers. The marquee selection is originating in track 1 (leader). Currently, this is what the selection on mouse down looks like:
Instead, what I am proposing is that because the selection originates on a leader track, the selection on mouse down should look like this:
If a selection originates in track 2, which is set to follow, not lead or lead/follow, and a selection is made, it should only select that one track as that is also what happens on mouse up as seen below:
In the next example, all 4 tracks are set to both lead and follow. So if the selection originates on track 4, this is what it currently looks like on mouse down:
With the proposal that if the selection originates on a leader track it selects all tracks in the group on mouse down, it would look like this instead:
Again, the selection on mouse down would apply to only a single group and be based on the selection originating on a leader track. If it originated on a track that was not set to follow, it would behave as it does now.
The benefit of this is that the selection on mouse down will be the same/similar as mouse up. There is no confusion as to what exactly is being selected. Making the user rely on some colored blips at the beginning of the track to determine what is being selected is just not intuitive - and honestly not even possible. Schwa rightly points out that this becomes an issue when selecting across multiple groups, etc. However, by simplifying the parameters, those issues don't come into play because 1) we are only worried about showing the selection of a single group in this proposal and 2) only if the selection originates on a leader track (including tracks set to both lead/follow).
And once the selection does go across groups, etc. it would basically function the same with the difference being the initial selection is showing all tracks in the originating group. IMHO this is better than what we currently have, especially as again, the most common use case in group editing is editing one group at a time, not multiple groups.
Instead, what I am proposing is that because the selection originates on a leader track, the selection on mouse down should look like this:
I believe less confusing would be adding dashed-line selection for the tracks you are not working on or while mouse button is not released, showing diagonal-line filled selection for those tracks, like this:
v6.72rc1 - December 6 2022
Linear Mode
