Help bugfixing a TJF Script

[chmaha]

I use the "TJF LINK Razor Edit Selection with Folders, Item Grouping Affects Behavior2(reapacktest).lua" script when working with folders to automatically extend a razor area to include the child tracks (script attached).

Unfortunately, something is amiss. After dragging a razor area over a destination set of items, the edges of the items are no longer consistent when moving them as a group:



When disabled and I manually extend the razor area over all the children, it works as expected:



Am I missing a simple script bug here?

[sonictim]

That is interesting. I wrote that script a long while back when razor edits were still very new. I’ll take a look and see if there’s anything I can do on my end. Though, I think my script just updates the razor edit, and doesn’t really deal with item properties / groupings. I wonder if theres been any changes to the API.

[chmaha]

Originally Posted by sonictim

That is interesting. I wrote that script a long while back when razor edits were still very new. I’ll take a look and see if there’s anything I can do on my end. Though, I think my script just updates the razor edit, and doesn’t really deal with item properties / groupings. I wonder if theres been any changes to the API.

Thanks for responding and for anything you might be able to do. Yeah, it's really odd. It's seems like it is the first of the items that always have the issue, either the dragged ones or the ones that are trimmed to make way.

[BirdBird]

This script mostly seems to contain (very old) code I wrote back when we got API for razor edits for the first time here.
It is likely that it will have to be tweaked when lanes and other changes make it into release, but I am not sure what is breaking item grouping here. Are you on a pre-release version by any chance? @BethHarmon

[schwa]

I don't think there's any real sense of "grouping" for razor edits. Afaict razor edit edges on other tracks are edited when they are within 1ms of the edge that is being edited by the user. So the issue may be that the script-created razor edit edge times are being rounded in a different way from the original razor edit edge times.

[chmaha]

Originally Posted by BirdBird

This script mostly seems to contain (very old) code I wrote back when we got API for razor edits for the first time here.
It is likely that it will have to be tweaked when lanes and other changes make it into release, but I am not sure what is breaking item grouping here. Are you on a pre-release version by any chance? @BethHarmon

No, I'm on v6.56...

[sonictim]

I'm having trouble replicating your bug on my end. I group the items, used that script to extend the razor edits, and then moved the razor edit. The newly moved chunk is a new group and acts accordingly.

The script itself runs in the background and only activates when it needs to extend the razor edits, and then returns to the background. Furthermore, it only manipulates the razor edit selections on the track and does not manipulate any item information or any kind of grouping behavior. It does check to see if Grouping is Enabled, but it does not alter the setting. So I'm not sure if your error is a result of the script, though your evidence does point to it.

I'm sure you've already done this, but can you make sure you have Options -> Item Grouping Enabled... and also check the following action state is set to on. "Options: Selecting one grouped item selects group"

[sonictim]

Originally Posted by BirdBird

This script mostly seems to contain (very old) code

Savage BirdBird! But true! =]

(I honestly don't think I've even opened reaper for well over a year until very recently)

[BirdBird]

Originally Posted by schwa

I don't think there's any real sense of "grouping" for razor edits. Afaict razor edit edges on other tracks are edited when they are within 1ms of the edge that is being edited by the user. So the issue may be that the script-created razor edit edge times are being rounded in a different way from the original razor edit edge times.

Thanks Schwa! The edges set by the API indeed seem to have less precision compared to the ones drawn by the user. However I can't seem to get the "1ms" difference to work, here even less than a single sample of difference throws off the group trim behaviour:

(I have set the ruler to display samples above)

Is there any way to have the values set by the API to have the same precision as the ones drawn by the user? (Even setting the same string gathered through the API seems to lose precision without doing any rounding/casting within Lua)
While I can keep everything in sync by pushing the same edits to all tracks through the API to fix the issue reported here I am slightly worried about this subsample difference compounding over time. (There is visible offset once things have been set this way through the API and duplicated enough times)


_

[schwa]

Are those razor edits?

[edit] sorry, I was not interpreting the screencap in the first post properly. Razor edit edges are edited together if they are within 1ms of each other. Media item edges are edited together if both items are selected and either the mouse modifier specifies "relative edge edits" (which is generally the default), or the media item edges are almost exactly the same (to 8 significant digits or so). The tolerance for media items is much more precise than for razor edits.

[BirdBird]

Originally Posted by schwa

[edit] Media item edges are edited together if both items are selected and either the mouse modifier specifies "relative edge edits" (which is generally the default), or the media item edges are almost exactly the same (to 8 significant digits or so). The tolerance for media items is much more precise than for razor edits.

Thanks for the reply! Is there a way I could set the razor edit edges with at least the same precision as the tolerance for media item edges in this case? (To not break group behaviour)
Track chunk line: AREASEL 13.7007874015748 14.64566929133858 "" 0 1 1
Same chunk line: AREASEL 13.700787 14.645669 "" 0 1 2
After running the following code:

local track = reaper.GetSelectedTrack(0, 0)
local _, sel = reaper.GetSetMediaTrackInfo_String(track, 'P_RAZOREDITS', '', false)
reaper.GetSetMediaTrackInfo_String(track, 'P_RAZOREDITS', sel, true)

[schwa]

Yes, we can increase the precision of the numbers returned by that API call.

[BirdBird]

Awesome, thank you Schwa


In the meanwhile for anyone that was relying on groups with the script in the main post I rewrote it (with a band-aid solution until the change Schwa mentioned makes it in) that works correctly with groups.

[chmaha]

Originally Posted by BirdBird

Awesome, thank you Schwa


In the meanwhile for anyone that was relying on groups with the script in the main post I rewrote it (with a band-aid solution until the change Schwa mentioned makes it in) that works correctly with groups.

Awesome, thanks! I'll give it a trial tomorrow AM...

EDIT: Any chance you'd let me include it in my classical tools metapackage with appropriate acknowledgments?

[BirdBird]

Originally Posted by BethHarmon

Awesome, thanks! I'll give it a trial tomorrow AM...

EDIT: Any chance you'd let me include it in my classical tools metapackage with appropriate acknowledgments?

Sure, I don't mind. However it is probably a good idea to wait until media item lanes make it into REAPER if you are planning to include it into any package that other people would also use.

[chmaha]

Originally Posted by BirdBird

Sure, I don't mind. However it is probably a good idea to wait until media item lanes make it into REAPER if you are planning to include it into any package that other people would also use.

Thanks. Interesting about the media item lanes but I'm not understanding the significance. For classical work, with my tools at least, I'm not recommending anyone work with take lanes but simple track folders and children. Any reason why I couldn't add it now and then when fixed media item lanes arrives I substitute with an updated script of yours and bump my metapackage version? I'm planning an update in any case to properly comment all the lua lines that have reaper.Main_OnCommand so people have a sense of what's going on...

[BirdBird]

Originally Posted by BethHarmon

Thanks. Interesting about the media item lanes but I'm not understanding the significance. For classical work, with my tools at least, I'm not recommending anyone work with take lanes but simple track folders and children. Any reason why I couldn't add it now and then when fixed media item lanes arrives I substitute with an updated script and bump my metapackage version?

I saw some API calls that can return more information regarding razor edits so I wasn't exactly sure if everything would work the same way. But I guess it will likely be fine, go ahead

[chmaha]

Originally Posted by BirdBird

I saw some API calls that can return more information regarding razor edits so I wasn't exactly sure if everything would work the same way. But I guess it will likely be fine, go ahead

Hehe, thanks. How would you like me to acknowledge you in the script? Does it have a GPLv3 license?

[Phfraiengngchkxzcs]

Hi,

Is there a way to consolidate the undo points with this script? I notice that when i'm running it, if a move an item to another track for instance, there are 4 undo points created: Unselect all tracks
Set first selected track as last touched track
Unselect all tracks
Set first selected tracks as last touched tracks

So undoing requires that I hit cmd-z 4 times.
Thanks! it's a great script otherwise. super useful to have a toggle for that functionality.

[Meo-Ada Mespotine]

Yes.

Include the followin line at the beginning of the script:

reaper.Undo_BeginBlock()

and the following line at the end of the script:

reaper.Undo_EndBlock("Razor Edit Selection with Folders, Item Grouping Affects Behavior2", 0)

and save it. This should consolidate the undo-points, if I got it right.