[MU4 Issue] Can't run mscore on terminal [QEventLoop: Cannot be used without QApplication]

[guyisra]

Describe the bug in MU 3, using mscore with -o to output to musicxml it would run flawlessly. in MU4, same command would result in prints of

QEventLoop: Cannot be used without QApplication QEventLoop: Cannot be used without QApplication

and not output anything

To Reproduce Steps to reproduce the behavior:

1. run mscore executable with -o (to export). eg. ./mscore -o myfile.mscz myfile.musicxml

Expected behavior output similar to MU3

Platform information

• OS: macOS

[AlexKnauth]

I get the same error when running mscore -j musescore-conversion-job.json on the command line.

[AlexKnauth]

From the bit of commit-history testing I've been able to do so far, I can reproduce this QEventLoop: Cannot be used without QApplication error message going back to 2021-11-23, and get a different error message around from 2021-06-10 through 2021-07-01.

In between those, for example around 2021-07-02 through 2021-11-22, I get segfaults and I don't know how to interpret those.

Before those, before around 2021-06-10, I'm not familiar enough with the commands to test this properly. (all of this is on the master branch)

[johentsch]

I've done some testing on Linux; depending on the output format, files are created, but alas....

Specs

I'm using the standalone AppImage on Manjaro Linux. The reported behaviour is consistent for the following two input files:

• n01.mscx an uncompressed MS3 file
• n01.mscz the same file stored with MS4

Terminal output

After each of the commands below the output to the terminal is

/usr/lib/libjack.so.0
/usr/lib/libnss3.so
QEventLoop: Cannot be used without QApplication
QEventLoop: Cannot be used without QApplication

File outputs

~/Desktop/MuseScore-4.0.0-x86_64.AppImage -o test.xml n01.mscx

outputs test.xml alright.

~/Desktop/MuseScore-4.0.0-x86_64.AppImage -o test.mscz n01.mscx

ouputs an empty test.mscz (size 0 bytes).

~/Desktop/MuseScore-4.0.0-x86_64.AppImage -o test.mscx n01.mscx

produces a behaviour that I have never experienced:

(Since the commands above specify no target directory for the output files, the TARGET_DIR is identical to the working directory output by pwd.)

• All files in the TARGET_DIR are deleted (including the MuseScore executable if it happens to be in the same folder)!!!
• In the file manager the TARGET_DIR turns blank, and ls returns nothing, however:
• Upon refreshing the file manager it does display the converted file(s) in MS4's Uncompressed MuseScore folder manner (see below).
• In the terminal, the files appear only after cd ../{TARGET_DIR}. This is fascinating behaviour because pwd outputs the exact same working directory before and after this cd command. It seems as if the conversion turns the target folder into a purgatory no-place.

After re-opening/refreshing the TARGET_DIR, it looks like this:

.
├── META-INF
│   └── container.xml
├── score_style.mss
├── test.mscx
└── Thumbnails
    └── thumbnail.png

The consequences of tacitly purging the target directory probably do not need to be elicited any further.

On a side note, simply zipping the "uncompressed MuseScore folder" into an .mscz leads to an Open error in MS4 saying that the file is corrupted. I had already noticed this behaviour in MS3: Apparently one particular kind of ZIP compression is required, not sure why?

Plea

I think I have understood the MS4 is supposed to output uncompressed data as a directory that looks exactly like the contents of an .mscz ZIP archive (in this case, however, without audiosettings.json and viewsettings.json). Not familiar with the reasons and discussions that have led to this new behaviour, I would like to plea for containing the old behaviour of simply outputting uncompressed .mscx files, if only for a single reason: version control.

We happen to curate score datasets for music research purposes (e.g., the Annotated Mozart Sonatas), which is why we use git version control to track the contents of the uncompressed MuseScore files. In research contexts, reproducibility and therefore version control, matter immensely (and less so, say, the viewsettings). Therefore I would like to strike a blow for maintaining the possibility of outputting .mscx file on their own (and without deleting all files around them, of course), because they autonomously purport the score contents.

Workaround

If anyone needs a workaround for batch conversion to MuseScore 4, I wrote one which you can use by installing ms3 in your Python 3.10 environment (pip install ms3) and then calling ms3 convert -d [source_dir] -o [target_dir] -m [musescore4executable] --format mscz. The workaround uses the conversion to "Uncompressed MuseScore folder" by creating a temporary directory. If the requested format is .mscz it zips the contents, if .mscx it simply copies the mscx file and deletes the tmp folder.

[igorkorsukov]

Warning about QEventLoop I fixed https://github.com/musescore/MuseScore/pull/15818 , but it doesn't affect anything

After the o command, there should be a path (file) to the exported format -o path/to/file.EXT
The file extension determines what exactly needs to be exported to
for example ./mscore -o myfile.musicxml myfile.mscz

Now we can export to such formats

[vanderaalle]

still having the same behavior OS: Ubuntu 20.04.6 LTS, Arch.: x86_64, MuseScore version (64-bit): 4.0.2-230651545, revision: github-musescore-musescore-dbe7c6d