Closing the project from macro

We can (I can) more on that tomorrow.

Peter.

It’s because .AUP are no longer a “native” project format, so they are imported rather than opened.


That may be a can of worms.

If we support “importing” AUP3 projects, then it could be very confusing when “opening” a project through file association (double clicking on an AUP3 file). Does the project “open”, or is it “imported”? We cannot guarantee that users won’t change the default double click behaviour, and the difference between “opening” and “importing” when Audacity is not currently running is subtle but important. If the project is “opened”, then the database remains open and the AUP3 is the “current” project, whereas if the project is “imported” then the database would be closed after import and it would be a new unsaved project with imported content.

I wasn’t thinking of allowing 3.0.x to “Import” AUP3 files - that is indeed a can o’ worms- in the early stages of UP development Leland allowed that - but it led to big unresolvable issues - that’s why we took it away.

I was actually thinking of changing Macros so that they could “Open” (not “Import”) a set of AUP3 projects and work on them - probably closing them on completion. This may need another button in Macros dialogs for “Projects” - but I’m thinking the existing “Files” button would do fine.

And ideally the user should be able to apply Macros to a mixed set of projects and audio files.

Peter.

Done here as you suggested:
https://alphamanual.audacityteam.org/man/Scripting_Reference

And also here as Msv264 suggested in their point no. 3:
https://alphamanual.audacityteam.org/man/Manage_Macros#command

Peter.

Done: https://alphamanual.audacityteam.org/man/Apply_Macro#Files

Thanks for the useful suggestions Msv264 :sunglasses:

Peter.

Thank YOU very much!
The Audacity is really GREAT system, and if my suggestions helped a little bit, I’m very glad.

Done: https://alphamanual.audacityteam.org/man/Apply_Macro#Files

It seems, the text needs a little correction:

A standard File Open dialog box will appear. Choose a directory then you can select one or any number of supported audio files in that directory, including Audacity AUP3 :question: :question: and older AUP project files.

I think the AUP file import may remain an “easter egg”

Peter.

Yes, but I was talking about aup3. It is a bit early to include it in this list :wink:

You can’t Import the new AUP3 - and thus you can’t work Macros on projects (except the current open, active, one).

And right now there are no plans to allow this.

Peter

Yes, I understand.
But if you look into the manual, it includes text:
A standard File Open dialog box will appear. Choose a directory then you can select one or any number of supported audio files in that directory, including Audacity AUP3 :question: :question: :question:
That is, Manual supposes, that you can select aup3 files in the dialog, where files for batch processing are selected.
Which is clearly not true.
The link to the page is
https://alphamanual.audacityteam.org/man/Apply_Macro#Files

Here is the foto of the manual page.
Screenshot_2021-04-12-19-56-37-631_com.android.chrome.png

Good catch Msv264, many thanks :slight_smile: :sunglasses:

I’ve fixed that:
https://alphamanual.audacityteam.org/man/Apply_Macro#Files

I was going to take out the reference to AUP files and leave that as a total “easter egg” - but I decided to leave it in (for now at least).

It also “nudged” me into noticing a couple of other corrections that were needed. And luckily it will make it into the 3.0.2 manual as we found a P1 bug today that will need fixing and a new Release Candidate - and thus a fresh pull of the Manual.

Thanks, very much appreciated,

Peter.

:wink:

Hello.
I am sorry to bother you again, but I still can’t solve the problem.
I tried to use Python scripting but it seems the “Close” command doesn’t work from script too. Here is the program:

import os
import sys

TONAME = ‘\\.\pipe\ToSrvPipe’
FROMNAME = ‘\\.\pipe\FromSrvPipe’
EOL = ‘\r\n\0’

TOFILE = open(TONAME, ‘w’)
FROMFILE = open(FROMNAME, ‘rt’)

def send_command(command):
TOFILE.write(command + EOL)
TOFILE.flush()

def get_response():
result = ‘’
line = ‘’
while True:
result += line
line = FROMFILE.readline()
if line == ‘\n’ and len(result) > 0:
break
return result

def do_command(command):
send_command(command)
response = get_response()

do_command(“OpenProject2:Filename="D:\Processing\!01_07.aup3”)
do_command(“Close:”)

TOFILE.close ()
FROMFILE.close ()
sys.exit ()

This program is based on the pipe_test.py that is supplied in manual.
Project opens ok.
When command “Close” is passed to Audacity, it just crashes.
I tried several files, different paths for file. The result is always the same.
I also tried to restart my PC - to no avail.
I enclose the Windows message with description of error (it in Russian, but the translation is very simple: “Program “Audacity…” doesn’t work.
Some problem caused program termination. Windows will close the program…”).
2.png
1.png

“Close:” works fine for me with “pipeclient.py”.

Note that “pipe_test.py” is only intended as a quick and easy way to check that mod-script-pipe is working.

pipeclient.py is here: https://github.com/audacity/audacity/blob/master/scripts/piped-work/pipeclient.py
Documentation is in the Docstrings.

I’m not sure if that was a typo, but you should avoid using special characters in file names (the exclamation mark “!”). Even if it is a legal file name (I think it is), I would not like to assume that the Windows Shell will be happy with it.

“I’m not sure if that was a typo, but you should avoid using special characters in file names (the exclamation mark “!”).”

I tried several different file names, it was just one sample.
For the file with another name (without ‘!’ in the beginning) it crashes too.
About the pipe_test.py - I tried to modify it, to add some other commands, and it works fine.
I can open project, make some other operations, but not “Close”.
But thank you for advice, I will try pipeclient.py.

I’ve not tested, but my guess is that with “pipe_test.py”, Python is hanging waiting for the response to the Close: command. If that’s the case, then hopefully it’s just because it is running in a single thread (which should be fixed by using pipeclient.py), but it could be a problem in the Windows implementation (I’m on Linux).

Try using pipeclient.py with the command line interface to see if Close: works (a quick and easy way to test).