Re: [Audacity-devel] Several "Export" commands for batch chains patch

[Joel B. <bo...@ho...>]

Hello,

Here are some remarks received from Martyn, which can be helpful for the group.
I have added extra explanations.

>> Hi Joel
>>
>> Thanks for you efforts here, which we appreciate.
>>
>> Unfortunately your patch has become so big that I don't think that
>> developers here can review it in sufficient detail to be able to apply it.
>>
>> I think that a way forward for your extensive changes may be a
>> plug-in, one that does all the 'batch processing' stuff that we
>> currently have in Audacity + your additions. We could then remove the
>> Batch stuff from the main-stream program and rely on a plug-in for it.
>> What do you think?
>>
>> TTFN
>> Martyn

==> I am presently cutting my work in several patches to facilitate reviewing.

> There are 12  newly implemented of modified Export commands:
> ExportAAC, ExportAC3, ExportAIFF, ExportAMR, ExportFLAC, ExportGSM, ExportMP2, ExportMP3, ExportOGG, ExportPCM, ExportWAV, ExportWMA.
> The source codes of these "effects" are very similar. Each is mainly a simple dialog box for entering the parameters. Coding was mainly "Copy & Paste"!
> Those dialog boxes are almost identical to the one used for the straight exportation, but they do not run the same code: the parameters used for the exportation in a batch chain are distinct from the parameters used for the straight exportation.
> Also those dialog boxes are implemented in classes inheriting from the "EffectDialog" class. Each dialog is launched by the standard "PromptUser", implemented together with other necessary virtual methods,  in dedicated "EffectExportXXX" classes inheriting from the "Effect" class.
> But, when executed, the "ExportXXX" effects run the code already existing for the straight exportation (and importation).

>> Wouldn't it be simpler (and less replicated code) to have a single fn 
>> to do this, and a switch statement in it?  Less code = less maintenance.

 ==> The new chain Export commands  "mimic " the already existing straight exportation commands.  For example the "ExportWAV" and "ExportAIFF" commands are subset of the "ExportPCM" commands as for straight exportation. This makes things simpler for the user.

My first idea was to re-use the code of the existing exportation commands, but this proved to be too difficult in practice. I should had used dynamic inheritance and mixing static classes with distinct instances of dynamic classes. Also the straight exportation commands use the "ShuttleGui" inheriting from "eIsCreatingFromPrefs" which automatically initialises the GUI values from gPrefs, while the effects use the standard "eIsCreating". The export effects must have their own preferences, distinct from the straight exportation preferences.
This would lead to a deep modification of the existing code with switches implemented in every method of the dialog class and also in the parameter transfer class. 
I have preferred implementing new code without modifying the existing code. But, you are right, this creates more code to maintain...

> Three Flags are implemented at the "Project" level to switch the execution between straight and batch exportation:
> MbBusyBatchApply: to avoid the messages which require user attention. (not acceptable in a batch).
> MbExportEffect: to fetch the proper parameters.
> MbNoExportParams: for the compatibility with existing chains without parameters.
>
> I think that implementing those ExportXXX commands as separated plugins would be difficult because they deeply rely on the code used for the straight exportation.
> But they can be split in several patches. For example the ExportAIFF, ExportGSM and ExportWAV are subsets of the ExportPCM format depending on "LIBSNDFILE". They can be integrated in a same patch.
> ExportAAC, ExportAC3, ExportAMR and ExportWMA depends on "ffmpeg" and they can be in a same patch. ExportMP3 and ExportMP2 depends on "lame" and "twolame", they could be associated.
> ExportOGG and ExportFLAC rely on different libraries, each can have its own patch or they can be put together.

==> I am presently working on this subject. The 4 patches for the commands based on "LIBSNDFILE" are already done but they still need further testing. I lack experience on SVN "merging" capabilities!


> The third feature is also relative to batch chains, but it is not connected to the ExportXXX developments.
> It is an extension of the "Apply Chain" dialog box which allows to choose the exportation directory.
> It also offers the facility to apply the chain to a set of files located in different directories, or to a whole folder of files, with the possibility to also process the subfolders. In this later case the hierarchy of the source directories is reproduced inside the exportation folder. The dialog box also offer the possibility to copy the non-audio files encountered during the importation, (unsupported files). This is useful for copying the Cue lists, images and other data useful data files included in the same directory as an audio file.
> I will create a separate patch for this feature. Steve has already started checking it on UNIX.
>
> Best regards,
>
> Joël                         
>