Per the issue reported at https://github.com/audacity/audacity/issues/2723, it sounds like there are reasons why “Editing a clip can move other clips” has changed to defaulted to off. However, this breaks macros with no clear explanation how to resolve it. That’s a problem now that this is the default behavior, because our instructions to users now need add for all users that they need to change that Preference checkbox for macros to work. Not complicated, but very counterintuitive.
More concerning, I see in that same GitHub discussion that the next version of Audacity, 3.3, may remove this option altogether.
If the option goes away, how do we preserve our macros? Currently, they all fail with the “There is not enough room available to paste the selection” error message if that option is disabled.
If you need help to reproduce my problem or believe that we need to change our macros to work without “Editing a clip can move other clips” checked, here’s an example of one such macro that yields the error (only if unchecked, works fine when checked):
Thanks for the suggestion to add the SetPreference line to the macro. That’s a great solution with the current version (3.2) and I will use it. But if the whole option really goes away in 3.3, then I suspect that will prevent that option from working in a macro too.
I was aware of that GitHub exchange. That’s where I also saw that the whole ability is being removed in the upcoming 3.3.
Will there be a broader work-around? I mean, will there be a new set of commands for copying and pasting a portion of the audio or inserting noise and silence via macro after these changes go through, perhaps by specifying which track is to be affected by the paste operation? It seems that having a way to do that would be a prerequisite to these changes. While I don’t want to have to update all our macros across all users, at least if it’s a one-time thing to support the new capabilities, that’s somewhat understandable. On the other hand, providing no alternative way to copy and paste via macro is not. Surely, I’m not the only one with that concern?
Steve, thanks and I understand. Is there someplace else that I should post my concern where it is more likely to be seen by the dev team? I can’t imagine would knowingly break macros without providing any mechanism to get them working again (bad enough that many macros will need to be edited to get it working), so I’d like to be sure they’re at least aware of these concerns. Or do you know if they are already aware of this specific consequence?