v6.64+dev0716 - July 16 2022

[sockmonkey72]

v6.64+dev0716 - July 16 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
• + Media explorer: support typing in preview volume
• # Track grouping: group items only if the leader item fully encloses the follower item
• # Track grouping: if contiguous leader items are selected, consider them a single item when calculating followers

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

[Zeno]

Originally Posted by sockmonkey72

• + Media explorer: support typing in preview volume

Thanks!

[Klangfarben]

Originally Posted by Sexan

There are scenarios where you need and where you don't.
Working on single track to fix some timing for example drummer is really REALLY bad, he missed the kick a lot so you need to fix the kick independently from overheads and room or to not make weird artifacts in them. OR some weird noise etc

But problem is this current behavior is its only good for splitting stuff and moving stuff ATM. Trimming/resizing, relative fades adjustment is a problem here:

1. You have drums tracks and remove bleed from xy track
2. Resize big chunks and you are also resizing that smaller chunks (this is normal)
3. Resize small chunks you also resize big chunks (this is a problem which requires disabling group)

So, I think there is a solution to this problem/use case so that the current behavior (fully enclosed) can be used without having to constantly group/ungroup as Sexan points out. It would involve a change to Reaper's grouping hierarchy so up to Schwa if he wants to go there, but it's a very tidy solution.

Which is sub-groups. So, let's say you have a drum group. Within that group you have toms, OH, and snare which you also want to group for editing. Right now in Reaper you have to make new separate groups for all of those. What would be better is if you could make sub-groups within the main drum group. So, if you click on one of the toms tracks, that sub-group would get selection/action priority and fade/move/split just those tracks. If you clicked on the drum leader track, it would then fade/move/split all tracks in the group. If you clicked on a follow track that wasn't part of any sub-group, it would act as normally in the drum group and if it was in lead/follow would again fade/move/split all the tracks in the drum group.

Here's a quick example of how that would work. In the example below, selecting the lead track in the drums group selects all the drum group tracks. Selecting the Toms only selects the Toms, not the full group. And so on.



So, if you click on a subgroup track item, that subgroup has priority over the main group for editing purposes.

You can do this with separate groups in Reaper, but there are a couple issues. One, to make it work similar to the above, you would have to set the main group tracks to one leader and the rest follow, not everything in lead/follow. If the tracks are all in lead/follow, then there is no way to select only the toms, only the overheads, etc. Also, you would lose the selection flexibility Schwa has added for contiguous leader items.

Also, and this is not something anyone has brought up yet but we're going to run out of groups with a current limit of 64. Especially if snare, toms, OH etc. all have to be a new group. Whereas if we had sub-groups within the main group that limitation wouldn't be quite as imminent. This would also really help with orchestral templates where you need a LOT of groups. Instead of having separate groups for strings, brass, woods, etc. you would have one Orchestra groups and multiple sub-groups for all the sections. In a template where you have drums, rhythm section, orchestra, etc. you are going to max out 64 groups pretty fast. Sub-groups would be a solution to that.

And more importantly, it addresses Sexan's concerns about having to constantly group/ungroup because clicking on a sub-group track item would have priority over the main group and be similar to a temporary ungrouping except you would still have the advantages of toms, etc. being their own (sub) group for editing. This would make using the "only fully enclosed" logic for group selection much more flexible.

[srdmusic]

Would it be possible to add an action to toggle on/off the new project setting "Auto-Bypass FX that report tail length or have auto-tail set"


This way I can write with the new setting but quickly toggle the setting off when printing, to avoid any possible print errors when an effect doesn't report tails correctly.

[Sexan]

This really feels and acts nice now (all lead scenario)!!



Btw there are still bugs with hidden tracks that were reported previous pre

[MonkeyBars]

Originally Posted by Klangfarben

So, I think there is a solution to this problem/use case so that the current behavior (fully enclosed) can be used without having to constantly group/ungroup as Sexan points out. It would involve a change to Reaper's grouping hierarchy so up to Schwa if he wants to go there, but it's a very tidy solution.

Which is sub-groups.

Group hierarchies would greatly improve track grouping usefulness outside these clear Media/Razor benefits as well. +1

[AZpercussion]

Yeah, this rule for fully enclosed items works fine as basic logic. And it's good for drums, but for sound design it would be better to have more advanced behavior.
And it could be added as an option!

I see such logic:
1. If item fully enclosed by lead item it marks as follower. (current behavior)
It allows small items being in two groups simultaneously if lead items are crossfaded. Exelent!
2. Else (if item is enclosed by leader one partially, no matter about percantage) seek for leader candidate and compare overlapped parts.
As I already drew here:
https://forum.cockos.com/showpost.ph...6&postcount=31


So this second point will not contradict with basic first one, but will complement it. And it could be as an option for those who afraid of corner cases.


Some about current bugs:

1. Coping by dragging doesn't works with autogrouped items.

2. Relative edge fade edit works for all grouped items even they are not selected.

It's behavior from regular grouping. But for auto one it's not convenient. Would be better if it will like with edge dragging: edit fades only for edges at the identical time.

Honestly I prefer such behavior for regular grouping too.
It forces me to toggle grouping very often.

3. Razor selction doesn't follow action "Options: Toggle item grouping override"

And could we have a modifier for making razor selection ignoring grouping?

[sockmonkey72]

Originally Posted by sockmonkey72

• # Track grouping: group items only if the leader item fully encloses the follower item
• # Track grouping: if contiguous leader items are selected, consider them a single item when calculating followers

This is fantastic, it's predictable, comfortable and works as I'd expect, and the rule can be explained in an elevator pitch.

Even if additional options for handling heads, tails, etc. never materialize, this is powerful enough to work with.

I think I found a bug with splitting:

• + Media explorer: support typing in preview volume

So just out of curiosity, did Jon report this, or did you watch his video and decide to add it? Thanks for the addition, it's very useful.

[schwa]

Originally Posted by sockmonkey72

watch his video and decide to add it

yeah

[MonkeyBars]

Originally Posted by AZpercussion

3. Razor selction doesn't follow action "Options: Toggle item grouping override"

And could we have a modifier for making razor selection ignoring grouping?

Zooming out here, I'm not really clear on why Media/Razor grouping are even toggled in tandem. Why aren't they two separate new track grouping toggles?

[schwa]

Originally Posted by sockmonkey72

I think I found a bug with splitting:

I don't think that's a bug. For items that are split, the default action selects the right-hand side of the split. Items that are not split are unaffected so their selection does not change.

[sockmonkey72]

Originally Posted by schwa

I don't think that's a bug. For items that are split, the default action selects the right-hand side of the split. Items that are not split are unaffected so their selection does not change.

For me, it feels wrong since the item was selectsd as a consequence of group membership, but not explicitly, if that distinction makes sense. I think that I would expect a new group selection based on the post-split items, with the odd item deselected.

But it's a detail, just thought I'd bring it up. Thanks!

[Klangfarben]

Originally Posted by sockmonkey72

This is fantastic, it's predictable, comfortable and works as I'd expect,

Agreed, this is very predictable now. And for the people concerned about catching tops/tails, this seems good to me as default behavior. I know there are users who will want to catch both tops/tails at the same time, but I think that should be an optional functionality/preference as the predictability is great right now.

Originally Posted by schwa

I don't think that's a bug. For items that are split, the default action selects the right-hand side of the split. Items that are not split are unaffected so their selection does not change.

This seems to be a little odd to me as well, although I understand your explanation. To me, since the selection of that item was based on the leader being selected, it should unselect when the new leader split item is selected as it is no longer fully enclosed. Bit of a gordian knot I guess.

[Sexan]

Originally Posted by sockmonkey72

For me, it feels wrong since the item was selectsd as a consequence of group membership, but not explicitly, if that distinction makes sense. I think that I would expect a new group selection based on the post-split items, with the odd item deselected.

But it's a detail, just thought I'd bring it up. Thanks!

+1 since in a little busy scenario it requires to select new region again to make adjustments or every item will be modified (especially in zoom scenarios where you do not see the entire selection but assume it)



If I've done cut or delete here that would be bad (this is just a simple example)

[AZpercussion]

I'm agree that it's odd to left the opposed items selected.

If action split and select right, then items ended left of split point should be deselected.
If action split and select left, then items started right of split point should be deselected.

Because mostly selection stays after previous actions.
It would be better to split and make addition selection sometimes than split and remove from selection often.

[bolgwrad]

Grouping is getting much more useful now. I don't know about anybody else but I've found it essential to add a track grouping parameters toolbar button, rather than (the defaults) right-click and scroll on a track menu, or even remember Shift+G.

[Triode]

Originally Posted by sockmonkey72

For me, it feels wrong since the item was selectsd as a consequence of group membership, but not explicitly, if that distinction makes sense. I think that I would expect a new group selection based on the post-split items, with the odd item deselected.

But it's a detail, just thought I'd bring it up. Thanks!

I agree with sockmonkey on this. Only to the right of the split point remaining selected feels right.
(And only to the left for the "split and select left" action)

[Justin]

Originally Posted by srdmusic

Would it be possible to add an action to toggle on/off the new project setting "Auto-Bypass FX that report tail length or have auto-tail set"


This way I can write with the new setting but quickly toggle the setting off when printing, to avoid any possible print errors when an effect doesn't report tails correctly.

Hmm how about a global option to not use auto-bypass when doing anything offline (render/print/etc)?

[lavmort]

Originally Posted by sockmonkey72

[*]+ Media explorer: support typing in preview volume

That's awesome!!!

[ovnis]

Originally Posted by lavmort

[*]+ Media explorer: support typing in preview volume

That's awesome!!!

What is it?!

[srdmusic]

Originally Posted by Justin

Hmm how about a global option to not use auto-bypass when doing anything offline (render/print/etc)?

Some might call that GENIUS!!!!

Thanks Justin!

[Sexan]

Toggling all track group enable does not update visual feedback (you can only see that items are not selecting in groups thats it)

[Mercado_Negro]

Originally Posted by Justin

Hmm how about a global option to not use auto-bypass when doing anything offline (render/print/etc)?

That would be great!

[musicbynumbers]

Originally Posted by ovnis

What is it?!

I think it means you can literally type in the exact number you want the media explorer volume to play back at

There is a box there with the current volume and now you can click into and enter a new value.

That's what I think it means anyway

[musicbynumbers]

Is it me or has anyone else found normal control+drag item copying (not razor or time selection) to be broken in this build when the tracks are grouped?

For me, it copies everything below itself (but on the same track) and then moves both old and new items together at the same time.

This happens for me even with two tracks slaved to each other with a single midi item of the same length on both tracks.

[Sexan]

Originally Posted by musicbynumbers

Is it me or has anyone else found normal control+drag item copying (not razor or time selection) to be broken in this build when the tracks are grouped?

For me, it copies everything below itself (but on the same track) and then moves both old and new items together at the same time.

This happens for me even with two tracks slaved to each other with a single midi item of the same length on both tracks.

Yeah I can confirm that, its copying and moving original at the same time

[schwa]

Copying should be fixed in the next +dev build.