Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 1856 - Applying Macros to Files is no longer a batch process
Applying Macros to Files is no longer a batch process
Status: RESOLVED QUICKFIXED
Product: Audacity
Classification: Unclassified
Component: User Interface
2.3.0
Per OS All
: P1 RepeatableAll
Assigned To: James Crook
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-24 08:03 UTC by Peter Sampson
Modified: 2018-08-20 11:45 UTC (History)
4 users (show)

See Also:
Steps To Reproduce:
1) create 3 WAV files in a folder 2) Tools > Apply Macro > Palette 3) choose Apply to Files 4) Select the three WAv files 5) Macros Palette dialog opens showing the 3 files to be processed 6) Export Audio dialog opens for for the first file 7) Observe that the location offered is the last export location used 8) Choose location and click on Save 9) Depending on your Prefs setting you may now see the "Edit Metadata Tags" dialog 10) If so click the OK 11) Macro export proceeds 12) observe now that you cycle through steps 9-11 twice, once for each of the remaining two WAVs
Release Note:
First Git SHA:
Group: ---
Workaround:
Closed: 2018-08-20 00:00:00
petersampsonaudacity: Regression+
petersampsonaudacity: Test‑OK‑Win+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Sampson 2018-03-24 08:03:45 UTC
When applying Macros to Files the process is no longer a proper batch-process. Instead the user is presented with a series of dialog interrupts requiring user 
action you always get the export location dialog for each file to be exported (what else you get depends on your preferences settings).  As default file location Audacity offers that location used for the user's last export.


Contrast this with Chains in 2.2.2 and earlier - where on selecting the files for processing Audacity just gets  on with the batch job (unless that is you still have set "on", default setting, the warning for importing uncompressed files - in which case you get it for every export until you turn it off).  Chains just creates a sub-folder called "cleaned" in the same location as the source files to be processed.


Accordingly this a major regression on 2.2.2 Chains and is likely to severely upset many of our Chains users, thus I have set this as P1 as we cannot release 2.3.0 like this.

See following Comment for summary of QA consensus recommendations for addressing and improving this for 2.3.0
Comment 1 Peter Sampson 2018-03-24 08:09:47 UTC
Bill Proposed (and QA supports) when applying a Macro to file(s):

1) The users clicks Apply Macro to Files
2) A “Save processed files to” dialog pops up - this could offer a default save location, such as Documents/Audacity/Macro Output. Or it could default to the previously-used output location (as the Export Multiple dialog does)
3) The user fills out the dialog and clicks “OK”
4) The Macro now runs without further user “interruption”, saving/exporting the processed files to the user’s desired location. 

Additionally QA consensus is that Apply Macro to Files should ignore and overide any user settings for
a) the warning on importing umcompressed files
b) the metadata editor

but overwrite protection needs to be applied.

See: https://wiki.audacityteam.org/wiki/Macros_discussion_page#Regression_testing_Macros_versus_Chains
Comment 3 Peter Sampson 2018-08-06 05:21:00 UTC
(In reply to James Crook from comment #2)
Testing on W10 with audacity-2.3.0-alpha-70

On first use I get the Warning for choosing import a copy or read direct from files - along with the "Don't warn again and always use this choice"

If I ignore checking the "Don't warn again ..." the I get it on each of the three imported files (making this non-batch).  But hat is a dumb thing to do - most sensible users will check that box having decided on their basic workflow choice.

Once that waning has been checked the macro is fully automatic batch - there are no metadata dialogs popped up - even though that option is on by default and thus on for my testing.

So I believe that this has been fixed