Bugzilla – Bug 2734
Apply macro may not create the macro-output folder in the source directory
Last modified: 2021-06-19 15:38:34 UTC
The steps also happen with Apply macro to Project where the macro contains an Import step and an Export step. Creating a new project causes a subsequent macro run to create the macro-output folder properly.
When applying macros to files in different directories, it soon becomes very tedious to have multiple "macro-output" folders. I'd therefore suggest that in fixing this bug, we add "Macro output" path to "Preferences > Directories" with the behaviour: 1. If Preference NOT SET, then files are written to a "macro-output" folder in the directory where the FIRST or LAST file was imported from. (Note that a Macro could import multiple files from different directories. The exact behaviour would need to be documented in the manual.) I think this is the behaviour in 2.4.2, but I've not checked what happens in 2.4.2 if a macro imports two files from different directories and then exports a mix. 2. If Preference IS SET, then files are written to the specified "macro-output" folder.
DEVEL - FIX MADE https://github.com/audacity/audacity/commit/9e3c98202f3c13ffe15f8d7d63b04736338ec8e5
Testing this on W10 and macOS 11.2.3 with Audacity 3.0.0 b73aa1c This appears to work well after James' recent fix. But is is mostly but not exactly as Steve prescribed in Comment #1 1) Part 2 is as Steve prescribed: >2. If Preference IS SET, then files are written to the specified >"macro-output" folder But Part 1 is not precisely as Steve prescribed >1. If Preference NOT SET, then files are written to a "macro-output" >folder in the directory where the FIRST or LAST file was imported from. If it is not set what Audacity does now is to send the macroed files to a) ...\Documents\Audacity\macro-output on Win b) ...Documents/macro-output on Mac c) Linux behavior unknown. Note carefully that this is a digression from current 3.0.0 and earlier behavioe where a macro-output folder is created (or used if one exists already) in the folder from where the files for Macro processing were stored. Not the "source directory" as outlined in the bug title I think the new (default) behavior is much to be preferred to the previous and thus I shall mark this as OK on Win and Mac. I shall hold off updating the Manual until we get consensus that this is a good fix. -------------------------------------------------------------------- There is a small residual improvement that I would like to see and this is a) the directory entry for Macros should be pre-populated with ...\Documents\Audacity\macro-output (or ...Documents/macro-output on Mac) b) the user should never be able to make the entry blank c) nor should the user be able to define an illegal location
Testing on Linux: If the macro output directory is not writeable, Audacity crashes on running a macro that exports audio. When the new preference is not specified: I think the new behaviour is likely to confuse users that are familiar with the old behaviour - it looks like the macro has silently failed.
> If the macro output directory is not writeable, Audacity crashes on running a macro that exports audio Is that true of exports too? Is that a regression on 3.0.0?
(In reply to James Crook from comment #5) > Is that true of exports too? Not a problem with normal export. If the Export directory is not writeable, Audacity shows an error when attempting to export: "Cannot export to <path-to-attempted-output-file>"
Re comment #6 And is the current behaviour on non writability of the output directory a regression on 3.0.0?
What happens if the user specifies an unwriteable directory for their Temporary files directory? a) Do we protect against that? b) do we get a crash ? c) does Audacity work for recording/importing ?
(In reply to Steve Daulton from comment #4) >Testing on Linux: >If the macro output directory is not writeable, Audacity crashes on >running a macro that exports audio. But apart from that (which should be a separate P2 bug - doesn't justify P1 as it's a "dumb-user" bug but P2 as we should protect against dunbness} does this fix work on Linux as it works on Win and Mac Steve?
(In reply to James Crook from comment #7) Testing an earlier version of 3.0.1 (d72a10), which I'm guessing is the same in this respect as 3.0.0: If the output directory for a macro is not writeable, it shows an error message: "Unable to open target file for writing" so yes, it is probably a regression against 3.0.0.
(In reply to Peter Sampson from comment #9) Not necessarily a dumb user. I've not tested comprehensively but there's probably several "not dumb" ways to reproduce the crash. > But apart from that ... does this fix work on Linux as it works on Win and Mac Steve? I think that depends what you mean by "work". As in comment 4, I think the new behaviour is likely to confuse users that are familiar with the old behaviour - it looks like the macro has silently failed. For anyone that has done any batch processing previously, it will be totally unexpected for the exported file to be written to "Documents" unless they are importing from "Documents". This change also makes it much easier to accidentally overwrite files, in part because users will not be aware of the new behaviour unless they read the appropriate part of the extensive documentation.
(In reply to Steve Daulton from comment #11) >As in comment 4, I think the new behaviour is likely to confuse users that are >familiar with the old behaviour - it looks like the macro has silently failed. Existing Macros run on files in 3.0.0 and earlier suffer from exactly the same lack of footprint acknowledging/confirming completion of the Macro (you and I had a discussion with Koz about this on the Forum recently when he was complaining about the lack of such "footprint" for his ACX Macro. >For anyone that has done any batch processing previously, it will be totally >unexpected for the exported file to be written to "Documents" unless they are >importing from "Documents". To ameliorate that I would suggest that when a Macro is run on files on successful completion a confirmation message is popped up in a dialog telling the user how many files were exported and which directory location they can be found in This would also add a completion "footprint" ameliorating the first point as well. This is an enhancement (and would be useful in the original Macros oh files handling too) so I shall write this up as an ENH >This change also makes it much easier to accidentally overwrite files, >in part because users will not be aware of the new behaviour unless >they read the appropriate part of the extensive documentation Actually this is no real change at all from the current 3.0.0 and earlier Macros handling on files. If you run the Macro again on the same files (and IRL those files may well have been changed) then the original exported files are overwritten - and silently so, without warning.
(In reply to Peter Sampson from comment #12) >This is an enhancement (and would be useful in the original Macros on files >handling too) so I shall write this up as an ENH See ENH Bug #2737 >ENH: When running a Macro on files there is no completion/success dialog
(In reply to Peter Sampson from comment #12) >> This change also makes it much easier to accidentally overwrite files, >> in part because users will not be aware of the new behaviour unless >> they read the appropriate part of the extensive documentation > Actually this is no real change at all from the current 3.0.0 and earlier > Macros handling on files. The difference is that it is now a lot easier to accidentally overwrite files. Example: If you batch processed files: .../Desktop/file1.wav .../Desktop/MyFile.wav .../Desktop/another.wav and then batch processed files: .../Music/songs.wav .../Music/MyFile.wav .../Music/one_more.wav Previously that would not be a problem because the two batches would create output files in separate output folders. Now it is a problem because, by default, the output from "MyFile.wav" in the first batch will be overwritten without warning by the output from "MyFile.wav" in the second batch. There is also the problem that if you batch process files that are in: .../Documents/macro-output/ then the input files are overwritten without warning. This would be unexpected for users that are familiar with the behaviour in any previous version of Audacity.
(In reply to Steve Daulton from comment #14) >Now it is a problem because, by default, the output from "MyFile.wav" in >the first batch will be overwritten without warning by the output from "MyFile.wav" >in the second batch. This is really a user problem- if they will insist on using non-unique filenames in different folders. Plus consider the use case of macro-output folder. In almost all cases that is hardly likely to be the final destination for the processed files, rather after Macro processing the user will take them from there and move or copy them to the proper required location. BTW the same is true for the 3.0.0 and earlier way of doing things. ------------------------------------------- A useful enhancement we could consider and one I would support would be to give the user an input field in macro processing dialog to tell Audacity explicitly where to store the processed files. Macros could then work just like the other 4 Directories preferences 1) If filled in - that is what is offered as a starter in the dialog 2) if blank - then last-used is what is offered as a starter in the dialog That would give us some nice consistency in Directories prefs - and make life easier for users, making the operation of Macros on files more "discoverable" I may consider logging this as an ENH later
(In reply to Steve Daulton from comment #4) >If the macro output directory is not writeable, Audacity crashes >on running a macro that exports audio. Logged as P2 Bug #2738 >Audacity crashes with Macros on files when the macro-output folder >is in an unwritable location
(In reply to Steve Daulton from comment #10) >Testing an earlier version of 3.0.1 (d72a10), which I'm guessing is >the same in this respect as 3.0.0: >If the output directory for a macro is not writeable, it shows an error message: >"Unable to open target file for writing" > >so yes, it is probably a regression against 3.0.0. Technically not a regression as in 3.0.0 and earlier we had no entry in Directories preferences for Macro Output.
(In reply to Peter Sampson from comment #8) >What happens if the user specifies an unwriteable directory for their >Temporary files directory? Logged as P2 Bug #2739 >If Temporary files directory is set to be unwritable then Audacity >has a catalog of errors
See also Bug #2740 >Directories in Directories preferences can be set to unwritable locations
Steve has created a Nyquist plug-in for any users who really prefer, and want to stick with, "the old ways". See this Forum thread: https://forum.audacityteam.org/viewtopic.php?p=422865&fbclid=IwAR36_Zbmtd8qyFb3gVUScydeXBxPT8LGB7lAPKAg5mEFqZqFR3eugLspFKY#p422865
(In reply to Peter Sampson from comment #20) Let's not forget that "the old way" (macro-output folder created in the source folder) was unintentionally broken (hence, a bug and regression) and the fix (new directories pref) was meant to restore the "old way" (that is, the correct behaviour) when the pref was left empty. It's not like we had a discussion and decided that there was a compelling reason why creating the macro-output folder in the source folder was a bad thing.
(In reply to Bill Wharrie from comment #21) >Let's not forget that "the old way" (macro-output folder created in the source >folder) was unintentionally broken (hence, a bug and regression) and the fix >(new directories pref) was meant to restore the "old way" (that is, the correct >behaviour) when the pref was left empty. Have I closed this bug - no, it's been deliberately left open ... >It's not like we had a discussion and decided that there was a compelling reason >why creating the macro-output folder in the source folder was a bad thing. I think you'll need to take that up with the doer-who-decided how to fix this when they did make a "fix". I merely tested and documented the "fix". I do however personally think that the new way is actually an improvement (I would have implemented it this way from the get go). But I have dog in this race - I never use Macros for processing files, only on projects for comparative speed-testing. I'm minded to see how many complaints surface as a result of this change. a) If it remains just a few then we can stick with this (and use Steve's magicke spelle plug-in for those who really want "the old ways"). b) If it's a lot then some more work will be needed on this bug.
I note that we are not getting many complaints at all about this.
