v6.72rc3 - December 8 2022

[Triode]

v6.72rc3 - December 8 2022

• * Includes feature branch: razor edits on master track envelopes
• * Includes feature branch: track grouping manager dialog
• * Includes feature branch: track media/razor edit grouping
• + ReaScript: improve JSFX name matching in TrackFX_AddByName() [p=2621360]
• + Track edit grouping: actions that split selected media items respect track edit grouping regardless of media item length/overlap
• + Track edit grouping: apply grouping when previewing razor edits
• # Grouping: use Track Grouping Matrix instead of Grouping Matrix in menus and dropdowns
  

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

[vitalker]

Originally Posted by Triode

[*]+ Track edit grouping: apply grouping when previewing razor edits

Brilliant! Thank you! Triode, can you confirm it is working as expected? I'd say yes.

[Triode]

+ Track edit grouping: apply grouping when previewing razor edits

Thanks for letting us try this. I'll definitely give it a spin and feed back here

[YuriOl]

+ ReaScript: improve JSFX name matching in TrackFX_AddByName() [p=2621360]

Excellent! Thank you!

[Klangfarben]

Originally Posted by Triode

+ Track edit grouping: apply grouping when previewing razor edits

This is really great. Thank you so much for this. Is there any chance of using the same logic for marquee select? Again, if it only applies to the initial group at the point of selection, I think that would still be an improvement so that mouse down selection state better reflects mouse up selection.

I think not to put too fine of a point on it, Schwa's example GIF (https://forum.cockos.com/showpost.ph...1&postcount=30) isn't a great real world editing example. It's much more rare one would be editing material across multiple groups at the same time. The only time I ever do that is when I'm using an ALL group - so the workflow being make edits on the current group, enable group all tracks for media/razor edit and make edits, disable ALL and then go back to editing single group.

The majority of group editing is going to be done similar to Triode's GIF (https://forum.cockos.com/showpost.ph...6&postcount=11)

I think when trying to wrangle what to display for group selection on mouse down, leaving it out entirely in order to better accommodate multi-group editing/selection isn't ideal as one use case far outweighs the other. Obviously, this becomes more complex as Reaper allows you to set tracks to lead, follow or both on an individual per-track basis (which is awesome) as well as put the same track in multiple groups but I don't think this should necessitate throwing out the baby (main use cases) with the bathwater (edge cases).

So thanks for listening and trying to find a way to navigate this. IMHO, this implementation in RC3 is already MUCH better!

[schwa]

Originally Posted by Klangfarben

This is really great. Thank you so much for this. Is there any chance of using the same logic for marquee select?

That would be a change in behavior, not just display. The same marquee selection on different grouped tracks results in a different set of selected items:

[vitalker]

Originally Posted by Klangfarben

Is there any chance of using the same logic for marquee select? Again, if it only applies to the initial group at the point of selection, I think that would still be an improvement so that mouse down selection state better reflects mouse up selection.

The problem with marquee selection is that it is not snapping to track heights and grid as razor edits do.

[Klangfarben]

Originally Posted by schwa

That would be a change in behavior, not just display. The same marquee selection on different grouped tracks results in a different set of selected items:

Thank you for pointing that out. So the issue/difference being on marquee mouse down, Reaper can't know what item(s) will ultimately be selected until they are actually selected (which then determines the selection of the other group track items) whereas razor edit is selecting an area so Reaper doesn't have to know. So you either have mouse down possibly not reflecting mouse up (if changed) or mouse up not reflecting mouse down (current behavior).

My only question would be, is changing the mouse down behavior using the same logic as razor edits in RC3 more beneficial than leaving the current implementation as is? Looking at it, it seems that the only scenario where this fails (mouse down does not match mouse up) is when selecting a fully enclosed item shorter than the other items on a leader track or an item that is outside the bounds of the other track items. Whereas, in the current implementation with the selection originating on a leader track, mouse down selection will always not match mouse up selection. Which means that changing the behavior would actually be more accurate than not changing - marquee mouse down not reflecting mouse up on edge cases only vs marquee mouse down not reflecting mouse up on all cases. Since again the most common use case is that grouped track items will be the same length.

In terms of existing behavior, this wouldn't change anything for non-grouped marquee selection. And since track grouping isn't yet officially released, existing behavior for grouped marquee selection doesn't really apply.

[Klangfarben]

Originally Posted by vitalker

The problem with marquee selection is that it is not snapping to track heights and grid as razor edits do.

Again, it would be based off the origination of the mouse down so whether it snaps to track height is immaterial. It is simply based on where the mouse is clicked on start of marquee select. If it happens anywhere on a leader track, it would use grouped marquee selection as razor edits are now doing. If you take RC3 for a spin, you'll notice that if you razor edit starting in a follow track, it is only selecting the items in that one track. If the razor edit starts on a leader track then it is showing the track grouping on mouse down.

I'm suggesting that doing that with marquee selection would still be better as most of the time mouse down selection on a leader track will then equal mouse up selection (with the exclusion of the example Schwa gives as well as items outside the bounds of other track items), whereas in the current implementation marquee selection on a leader track will most of the time not equal mouse up selection. Since this is the case, I'm making the argument that it would be more beneficial to prioritize the main use case and have mouse down selection match mouse up selection most of the time vs prioritizing the edge cases and having mouse down selection not equal mouse up selection most of the time. If it's going to be wrong, I'd rather have it be wrong less vs what it is doing now.

And keep in mind, razor edits can be set to ignore snap just as marquee select can be set to snap.

[schwa]

There would also be the issue that previewing the grouped marquee selection would create the impression that envelope points and track envelopes displayed in the media lane of grouped tracks should be selected, but they wouldn't be. So it would not be wysiwyg anyway.

[vitalker]

Originally Posted by schwa

There would also be the issue that previewing the grouped marquee selection would create the impression that envelope points and track envelopes displayed in the media lane of grouped tracks should be selected, but they wouldn't be. So it would not be wysiwyg anyway.

That's because razor edits can be non-contiguous and marquee selection can't be, right? So if you have, let's say, 9 tracks and first and 9th are grouped, so marquee will select everything in-between, too, which won't happen in case of razor edits.

[Klangfarben]

This is always difficult to visualize so here are a few GIFS that might help clarify my point.

Schwa rightly points out that modifying marquee group select on mouse down to match razor edit mouse down is not ideal in edge cases. Here are the two edge cases I see that would be problematic.

In the first GIF, the user marquee selects in a leader track in Group 1. On mouse down it is selecting the group. But then the user selects just one item outside the bounds of the other items, so on mouse up only that one item is selected (please keep in mind, I'm using razor select here in lieu of marquee edit as marquee selection doesn't currently have the functionality to display these edge cases).



Same thing in the second GIF (which is essentially the GIF Schwa illustrated). The user again marquee selects on a leader track. On mouse down, it is selecting the group but the user ends up selecting an enclosed item so on mouse up, just that item is selected.



These are the two edge cases that fail. However, it should be pointed out that this is not a normal item configuration in track group editing. In most cases, the items will look like Group 2 does in the below GIF. This GIF shows the current implementation where if you marquee select on a leader track, mouse down will not match mouse up selection.



To me, the first two GIFS showing a grouped selection on mouse down and a different selection on mouse up is less problematic than the third GIF which shows no grouped selection on mouse down and grouped selection on mouse up. Especially since the first two GIFS "fail" in just those two edge cases. The third GIF "fails" in the most common use case. So the question becomes do we want this to fail for the most common use case and if not, then are we ok with the edge cases failing in the first two GIFs. IMHO, the third GIF showing the current implementation is more blind than the first two GIFS that show what it would look like if marquee group select was changed to match razor edit group select.

[vitalker]

@Klangfarben, was the last comment for me or schwa? Are you saying RC3 has bad behavior now, so the devs should revert changes as they were in RC2? Or you want just similar implementation for marquee selection?

[Klangfarben]

Originally Posted by vitalker

@Klangfarben, was the last comment for me or schwa? Are you saying RC3 has bad behavior now, so the devs should revert changes as they were in RC2? Or you want just similar implementation for marquee selection?

I'm arguing that marquee group selection would be better served matching the razor edit group selection of RC3. The above GIFS show what would happen regarding edge cases if it was changed (first two GIFS) vs the current implementation (third GIF). The downside of the third GIF outweighs the downside of the first two IMHO, especially since they are edge cases whereas the third one is definitely not.

[schwa]

In the interest of preventing this thread from getting too far down a speculative road, after doing some testing here, I think grouping item selection marquee preview won't work. Too many corner cases. The razor edit grouped preview is good though.

[Triode]

There's also the option of letting marquee selection completely bypass track grouping.
We will have razor edits that obey track groups which is a game changer along with click item selection (of equal length item areas) for track groups.
Is marquee item selection more valuable if it bypasses track grouping?

[AZpercussion]

+ Track edit grouping: actions that split selected media items respect track edit grouping regardless of media item length/overlap

Thanks for that, it seems better anyway. Though item selection choosing is a hard kvest, but such splitting feels right.

Else:
Here several points I mentioned. Hope this gif shows it clear.



1. If only one track selected there is no reasons to prevent changing track selection by clicking on or editing items.

2. This weird prevention works even auto-grouping is off.

3. The line "Enable track grouping" switches both grouping for arrange edits and for TCP controls. We have separate option for item grouping, but not for TCP controls.
I think there could be situation when user need to switch TCP grouping off but preserve grouping for editing.

4. Also it would be nice to have in that dropdown menu a line for opening Track Group Manager, not only matrix.

[Klangfarben]

Originally Posted by schwa

In the interest of preventing this thread from getting too far down a speculative road, after doing some testing here, I think grouping item selection marquee preview won't work. Too many corner cases.

Thanks for considering it. To be fair, this is being introduced in an RC, so there really isn't another thread to comment. Maybe it could be looked at in the next dev cycle so the discussion wouldn't clog the release getting out? I understand the corner case issues, but I also don't want to throw something out entirely when possible alternatives haven't really been looked at or discussed.

Originally Posted by Triode

Is marquee item selection more valuable if it bypasses track grouping?

I'm not sure really. If it does bypass track grouping entirely the one large disadvantage you would have is it would take much longer to make a larger selection. Whereas if it does conform to grouping you aren't having to do so much mousing to select the items you want.

[Triode]

Originally Posted by Klangfarben

If it does bypass track grouping entirely the one large disadvantage you would have is it would take much longer to make a larger selection. Whereas if it does conform to grouping you aren't having to do so much mousing to select the items you want.

Isn't there an action that selects items from a razor edit? That would do the trick. (I can't find it in actions though...where did it go?)

The other side of the coin is that marquee selection could be a quick way of selecting clusters of items without having to disable grouping. It might be worth at least having an option in mouse modifiers to marquee select items and ignore track grouping (or a tick-box that affects the toggle selection and add to selection counterparts also)

[Triode]

Is the mouse modifier for "Toggle item selection" not working when tracks are grouped?

Here I'm first selecting a line of items when track grouping is turned off and then toggling them off via that mouse mod. Then I enable track grouping and try the same thing. This modifier seems to only select items in a group but not de-select them.

Edit: This only affects item (top half) select on my system because I have the upper half command drag modifier set to "Select time ignoring snap" which seems to be blocking the item click for track grouping
(The bottom half left drag modifier is set to an item-related one "move item ignoring snap")
If I set the top modifier to an item-related action then grouped toggle clicks work with this modifier.

NB when I made my track grouping action scripts I remember I had to get around this same problem by changing how the item under the mouse was selected in the script.

[Triode]

Please let this not be a bug that causes the removal of grouped razor edit preview (generally it feels good to use).

The RE dissapearance happens also when dragging the lower initial selection down to extend into the envelope area.
Note the second time I draw the initial razor edit and finish it off as if the tracks weren't grouped it doesn't happen

This whole scenario doesn't occur in 6.72rc2 (boo)

[AZpercussion]

Originally Posted by Triode

Is the mouse modifier for "Toggle item selection" not working when tracks are grouped?

The same via right drug. It's ok that this action respect grouping, but it's called "toggle". I can select now, but not deselect items. And when autogrouping is off I can both.

[Triode]

Originally Posted by AZpercussion

The same via right drug. It's ok that this action respect grouping, but it's called "toggle". I can select now, but not deselect items. And when autogrouping is off I can both.

AZ, do you also have a non-item-related left-drag action mapped to the same modifier key as your "toggle item selection"? Try changing that to an item-related one and see if toggle select starts working in the track group

[AZpercussion]

It might be that way the locked item can be edited if the user edit it directly. Kind of smart behavior.
But it works the opposite.

And yeah, this smart behavior doesn't exist in Reaper yet, so it would be inconsistent. Maybe in future...

[AZpercussion]

Originally Posted by Triode

AZ, do you also have a non-item-related left-drag action mapped to the same modifier key as your "toggle item selection"? Try changing that to an item-related one and see if toggle select starts working in the track group

Do you mean the left drag and the right drag have relationships?
I have "Move item ignoring snap and time selection" at left drag+shift and "Toggle item selection" at the right+shift.
It seems they don't influence each other.
Anyway, toggle should work in both directions.

[Triode]

Originally Posted by AZpercussion

Do you mean the left drag and the right drag have relationships?
I have "Move item ignoring snap and time selection" at left drag+shift and "Toggle item selection" at the right+shift.
It seems they don't influence each other.
Anyway, toggle should work in both directions.

I mean that left drag has a blocking relationship with left CLICK in grouped tracks if left drag is mapped to a non-item-related action

[mlprod]

Please don't change how marquee selection works.

[AZpercussion]

Originally Posted by mlprod

Please don't change how marquee selection works.

Here is no talks about changing how it works in currently possible cases.
The question is how it should work in new cases which we get from new feature.

[AZpercussion]

I've looked at marquee selection as a solution for tails problem.

Could we have this suggested marquee selection (behaving like razor in current rc) optionally?

So, if some items aren't in group because of unique fades/crossfades and we cant't choose them all by clicking at one of them, we can use marquee selection catching all items in follower tracks automatically.

We should be careful at edges where we can grab neigbour items, but as option it would be useful.
It really can close most of cases. Because if we use autogrouping the items will not have too mich differencies in their lenght, just some optimizations.

[amagalma]

Originally Posted by mlprod

Please don't change how marquee selection works.

I agree! The new RE selection visuals are super though!

[soulaccess]

I think a new problem with TrackFX_AddByName() was introduced in 6.70 when this problem here got fixed:

Originally Posted by sockmonkey72

v6.70rc1 - November 14 2022

• + ReaScript: improve behavior with Track/TakeFX_AddByName() for JSFX [t=271878]

unfortunately this recent fix does not help:

Originally Posted by Triode

v6.72rc3 - December 8 2022

• + ReaScript: improve JSFX name matching in TrackFX_AddByName() [p=2621360]

the problem is: when you pass the name of an FX (as defined by the desc: tag) to TrackFX_AddByName(), it often fails (just an blank fx appears) - this used to work just fine pre 6.70
when passing a filename of an FX to the function it works as expected.
seems to happen on Mac & Win, but not on Linux(?)

[Justin]

Originally Posted by soulaccess

I think a new problem with TrackFX_AddByName() was introduced in 6.70 when this problem here got fixed:

unfortunately this recent fix does not help:



the problem is: when you pass the name of an FX (as defined by the desc: tag) to TrackFX_AddByName(), it often fails (just an blank fx appears) - this used to work just fine pre 6.70
when passing a filename of an FX to the function it works as expected.
seems to happen on Mac & Win, but not on Linux(?)

Ahh, it depends on the JSFX display options in the FX browser, it seems. Fixing.

Btw, in 6.69 and earlier passing a name didn't work _at all_. Can you confirm that?

[soulaccess]

Originally Posted by Justin

Ahh, it depends on the JSFX display options in the FX browser, it seems. Fixing.

Btw, in 6.69 and earlier passing a name didn't work _at all_. Can you confirm that?

No, to the contrary, passing a name used to work fine in 6.69 and earlier.
Thanks for looking into it!

[Justin]

Originally Posted by soulaccess

No, to the contrary, passing a name used to work fine in 6.69 and earlier.
Thanks for looking into it!

Are you sure, have you checked? Looking at the code it shouldn't have (unless the name happened to be the same as the filename!)

[soulaccess]

Originally Posted by Justin

Are you sure, have you checked? Looking at the code it shouldn't have (unless the name happened to be the same as the filename!)

Yes and yes. I just double checked, installed V6.69 and FX names work perfectly fine - also tested with names that are completely different from the file name. It just works somehow. This is on macOS Mojave, btw

[Justin]

Originally Posted by soulaccess

Yes and yes. I just double checked, installed V6.69 and FX names work perfectly fine - also tested with names that are completely different from the file name. It just works somehow. This is on macOS Mojave, btw

Make me a screen recording, I think it might be user error :/

[soulaccess]

here you go, sorry for the low quality, not sure how others upload screen caps in pristine quality.
first I show the script, which is simply:

track = reaper.GetSelectedTrack2(0, 0, true)
reaper.TrackFX_AddByName(track,'test for justin',false,1)

then I execute it, FX opens. I click on edit and the code starts with:

desc:test for justin

the FX file is here

REAPER⁩/Effects/BNC⁩/TestPlugin.jsfx

Reaper V6.69
hope this helps

[vitalker]

Originally Posted by soulaccess

here you go, sorry for the low quality, not sure how others upload screen caps in pristine quality.

We use external services like https://stash.reaper.fm/ https://imgur.com/ etc.
For GIF recording we use:
http://cockos.com/licecap/

I usually set it to 5-6 FPS.

[Justin]

Originally Posted by soulaccess

here you go, sorry for the low quality, not sure how others upload screen caps in pristine quality.
first I show the script, which is simply:

track = reaper.GetSelectedTrack2(0, 0, true)
reaper.TrackFX_AddByName(track,'test for justin',false,1)

then I execute it, FX opens. I click on edit and the code starts with:

desc:test for justin

the FX file is here

REAPER⁩/Effects/BNC⁩/TestPlugin.jsfx

Reaper V6.69
hope this helps

It's very clearly opening the wrong plug-in (what's all that UI? the TestPlugin.jsfx was an empty jsfx!)...

[soulaccess]

Originally Posted by Justin

It's very clearly opening the wrong plug-in (what's all that UI? the TestPlugin.jsfx was an empty jsfx!)...

hmm, no, it's the correct plugin, I just made the window small for the screen cap so the rest of the code is hidden. it's an FX I have written (that's all the UI).
It's ok, I just wanted to help, I'll use the file name in the future. no worries.