Talk:Macros discussion page

From Audacity Wiki
Revision as of 12:38, 24 March 2018 by PeterSampson (talk | contribs) (Quality list email thread: Steve's respomse)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Quality list email thread

Peter: I have spent some time today regression testing 2.3.0 latest alpha Macros versus Chains in 2.2.2 - and I have uncovered two regressions on 2.2.2 and earlier - and identified one risky bug in 2.2.2

All tests done use the supplied/bundled "MP3 Conversion" Macro

And bear in mind that on this page in the Manual:

it states quite clearly:

The exported files will be saved in a folder named "cleaned"

If the audio in the project came from an imported file or files, the "cleaned" folder will be inside the directory from which the first file was imported. The original files are not altered. Otherwise, a message prompt will indicate the location of the "cleaned" folder that will contain the exported file. The "cleaned" folder will be in the last location that the Macro process exported to. If the Macro process has never been used for export before, the "cleaned" folder will be in the location at which the File Export Dialog currently opens.

A) Applying Macros to the existing project

With 2.2.2 Chains

  1. Open Audacity
  2. Drag&drop drop an mp3 file from Desktop
  3. File>Chains>Apply Chain... and choose MP3 Conversion and "Apply to current project"
  4. no file location dialog is offered - Chains just gets on and does it with no further user input
  5. Audacity creates a "cleaned" folder on my desktop - and the resulting mp3 file is placed in that folder

Although when I repeated this test with an unnamed project and track at Step 2 the "cleaned" folder is created in the default ... Documents\Audacity folder BUT with a mixture of Windows/Mac backward/forward slashes (minor bug I'll report elsewhere)

And if I then save the project to desktop and re-run MP3 conversion - it places a "cleaned" folder with the MP3 file in it to the desktop (i.e.the project file location)

With 2.3.0 alpha Macros

  1. Open Audacity
  2. Drag&drop drop an mp3 file from Desktop
  3. Tools>Apply Macro>MP3 conversion
  4. result is I am offered exactly the same mp3 file location on my Desktop in the export dialog and I am asked if I want to overwrite it.
  5. No "cleaned" folder is created as the documentation says.

Testing with the new un-named project with 2.3.0

  • without clearing out the config files it created a "cleaned" folder on the desktop - presumably as the last file location used above
  • with configs cleared - with an empty project - once again Audacity interrupts and offers the user file locatioion ...Documents/Audacity and the unnamed.mp3 is placed there with no creation of a "cleaned" folder as the Manual suggests.

So the 2.2.2 Chains way is more automatic as the Macro does not get interrupted for user input. Plus 2.2.2 Chains is in agreement with what the Manual says - 2.3.0 Macros is thus a technical regression.

The fundamental question is: which behavior do we prefer ?

Personally I find myself preferring the more automated way of 2.2.2 Chains - Macros are really supposed to an automated batchy process - so for me this is definitely a regression.

I also expect that existing users of Chains would regard the 2.3.0 Macros behavior regressive in this respect.

B) Applying Macros to a file

With 2.2.2 Chains

  1. open Audacity
  2. File>Chains>Apply Chain... and choose MP3 Conversion and "Apply to files..."
  3. select file to be processed
  4. Chains just went ahead an did it and created a "cleaned folder" on my desktop (original file was on desktop)
  5. and then put then put the processed mp3 file in that folder (just as the Manual says)

With 2.3.0 alpha Macros

  1. open Audacity
  2. Tools>Apply Macro>Palette
  3. choose apply to Files
  4. select file for processing
  5. Audacity created a "cleaned" folder on my desktop
  6. popped the interrupting Export dialog offering "cleaned" as its proffered location
  7. press OK to accept (and get further interruption with metadata dialog)
  8. processing proceeds
  9. Result: 2.3.0 Macros produces a second "cleaned" folder inside the one created at a) and the exported MP3 sits in that sub-level folder (not what the Manual says!)

So not only do we get the regression of interrupting the automated process with requests for user input - we also get the bug of the nested "cleaned" folders.

Once again I find myself preferring 2.2.0 Chains behaviors - and regard this as a regression too.

Bug in 2.2.2 Chains

BUT there is an un-warned overwrite danger in 2.2.2 Chains:

  1. run MP3 conversion as above for an existing desktop MP3 file
  2. double the Audio length with a 1 x Repeat
  3. re-run the MP3 Conversion Macro
  4. result: Macro runs and silently overwrite the existing MP3file in the cleaned folder with no warning issued to the user

The current regressive behavior of 2.3.0 alpha Macros side-steps this issue with its user interrupts for file locations - and goes on to issue an overwrite warning if the user does not change the filename - but the overwrite is allowable of course.

I would suggest that at step 4 we should convert the MP3 and write it back to a similar but augmented filename.

I will log this as a P3 2.2.2 Chains bug on Bugzilla (in case we regard 2.3.0 Macros behaviors as regressive)

Bill replied

Thanks, Peter, for the rigorous testing. I, too, had noticed the “interrupting” export dialog when applying a macro to files and thought that needed to be addressed.

  • When applying a macro containing an export step to a project, I think the export dialog is acceptable.
  • When applying a macro containing an export step to files (and any macro applied to files would have to contain an export step or it would be useless, right?), my suggestion is:
  • when the macro is invoked (either before or after choosing the files), pop up a dialog (similar to the Export Multiple dialog) that allows the user to set:
    • the export folder
    • a prefix or suffix to add to the exported filenames (including none)
    • option to suppress the metadata dialog
    • option to allow overwrite.
  • at the end a summary dialog is displayed, again similar to the once displayed at the end of Export Multiple.

As I noted, it would be silly to apply a macro to files if it didn’t have an export step. Do we want to protect users against this by disallowing “apply to files” if the macro does not contain an export step?

I notice the new “Export MP3” step does not include any parameters. Perhaps it should specify at least an MP3 preset, or the options shown in the Export dialog when exporting an MP3. Similarly for FLAC.

Steve replied=

When Chains were added to Audacity, we combined two similar but distinct features common to many editors:

  1. Macro commands
  2. Batch processing

A typical use case for macros is that the user has a "procedure" (set of step) that they frequently use when working on a project. For example, after importing a file, they may commonly apply DC offset correction + normalize + rumble filter. Macros are a way of combining a sequence of events like this into one callable command, so that any time the user wishes to apply this sequence, they can just call the macro and it will apply the effects sequentially.

A nice feature that some other applications have, is the ability to "record" a macro.

How this works, using the example above:

  1. Import a file
  2. Start "Macro record"
  3. Apply Normalization with DC offset correction
  4. Apply Rumble filter
  5. Stop Macro record.
  6. Save the Macro with a name.

The macro can then be called in the future by the name given in step 6.

A macro could include an "Export" step. For a macro, the way that our "new" macro feature works would be both expected, and probably the most useful. Putting the exported file in a special "cleaned" folder, the location of which is determined by the application, is not only unexpected, but probably also an annoyance for this type of workflow.

The significant feature of "batch processing" is that you have a bunch of files, and you want to do the same thing to each of the files. A typical example is that you want to transcode the files from one format to another. In this use case, interrupting the operation to prompt for the export location largely defeats the point of batch processing.

While a specialist batch processing application may offer a wide range of highly configurable options for where it puts the processed files, Audacity is not specifically a batch processor and I don't think we should go down the path of dozens of export options. I think what we want is something safe, simple and reliable.

What I would suggest is that for "batch processing", we always prompt for a folder to put the exported files in, and always prompt before overwriting a file. This means that once the "batch" has been started, provided that a new empty folder was selected / created and no error is encountered, the entire batch will run to completion unattended.

Item withdrawn for lack of support/consensus

Standard output folder location

Peter: I personally would like to propose simplifying the process by always writing to exports to a fixed file location and I would suggest:

... Documents \ Audacity \ Macros Output

That way:

  1. there would be no need for dialog as in b) above
  2. users wouldn't get "cleaned" folders all over the place (making searching with file finders easier)
  3. users would always know exactly where to look for their exports (I fell foul of this while testing)
  4. it makes it simpler for us Forum Elves to tell users where to look
  5. It would simplify the Manual's instructions (which currently are a little tortuous)
  6. as an additional benefit the nomenclature "Macros Output" would be clearer in it's intention/purpaose cf. "cleaned"