I was playing around with the mod-script-pipe module in an attempt to include audacity to my Makefiles and command batches. My main motivation was the ability to export Audacity projects to flac in bulk. The result of my playing around is a shell script called audacity-bridge that starts Audacity, passes the input as messages to the mod-script-pipe module and then shuts Audacity down. It sort of works, but there are several known issues. I’m curious, if any of these issues could be eliminated without updating the mod-script-pipe module, or if they are inherent to the current version of the module.
Mod-script-pipe is experimental so totally at your own risk (but thanks for trying it).
You can run two Audacity instances (but not currently on Windows) by adding a “Portable Settings” folder to one of the folders Audacity is run from.
The mod-script-pipe interface is blind and therefore brittle. Suppose a modal dialogue pops up, when Audacity starts up (f.ex. an orphaned files warning). This dialogue prevents the project file from being loaded, but the audacity-bridge client has limited means of detecting this.
While the Audacity splash screen is displayed, incoming messages are silently gobbled. This is handled by adding a fixed sleep at the beginning of the script, but this solution is brittle.
Upon receiving the Exit MenuCommand, Audacity crashes. The audacity-bridge handles this internally, so no action is required on the part of the user.
I assume those three are our bugs or limitations. Someone else said that when controlled by mod-script-pipe, Audacity crashes on quit on Linux. What OS are you on?
What I meant was the ability to run two Audacity instances at the same time. That does not seem to be possible, but even if it were, mod-script-pipe creates a single pair of pipes per a user (not a process), so there would be currently no way to address the individual instances.
Someone else said that when controlled by mod-script-pipe, Audacity crashes on quit on Linux. What OS are you on?