You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To report how many items were removed, OSARA saves the number of items before the action runs, then runs the action, then gets the number of items now, then subtracts the latter from the former. My guess is that because you're rippling all tracks, when you delete a whole item on one track, unless the items on all tracks line up precisely, REAPER has to split items on other tracks. So, even though you removed an item, there are now actually the same number of items: minus 1 for the removal, but plus 1 for the split.
I'm not quite sure how to fix this. We could look at the number of selected items before the removal instead and just assume they were all removed, but that's risky. We have no guarantee that REAPER actually removed only (or all of) those items, so we'd effectively be guessing, and I don't like guessing.
I guess the assumption would be fine if we're certain those commands always operate on all selected items. However, I've just confirmed that item locking will prevent items from being deleted, so we'd have to handle that somehow.
Another possibility might be to store a list of items and call ValidatePtr on them all after we remove them, counting the items that fail to validate. That leaves the question: are there any of these item removal commands (bound to cmdRemoveItems or calling cmdhRemoveItems) which operate on anything other than selected items?
Came across this yesterday while editing a two-track project.
Doing the same in a single-track project works as expected.
OSARA 24.03.10, REAPER 7.11 under MacOS Sonoma 14.4. No changes to keymap.
The text was updated successfully, but these errors were encountered: