(Optional) non-blocking calls of MuseScore to show/play musicxml output

[dvrehen]

Would be great if score.show('xml') wouldn't block the execution of a script until the MuseScore instance displaying the musicxml-file is closed down. Similar request as this:

https://stackoverflow.com/questions/64949701/stream-show-without-interrupting-code-in-music21-similar-to-matplotlib-pyploy

But subprocess.run is a blocking call, subprocress.Popen is the non-blocking call

Motivation
Improve usability in a scripting environment like PyCharm

Proposed implementation

I fixed it locally in subConverters.py, line 205:

        #subprocess.run(cmd, check=False, shell=shell)
        subprocess.Popen(cmd, shell=shell)

But don't know enough about the code structure to know if this will cause problems with other converters.

Intent

[X ] I plan on implementing this myself.
[ ] I am willing to pay to have this feature added.
[X ] I am starting a discussion with the hope that community members will volunteer their time to create this. I understand that individuals work on features of interest to them and that this feature may never be implemented.

[mscuthbert]

What's your operating system and music21 version? On Mac (Sequoia) with M21 9.3 there's not a problem with hanging on the current music21.

[dvrehen]

Using the current github-cloned code on Windows 10.

Some grain-of-salt wisdom from ChatGPT:
"How come "subprocess.run(cmd, check=False, shell=shell)" in Python is non-blocking on MacOSX and blocking on Windows?

ChatGPT said:
The behavior you're observing—where subprocess.run(cmd, check=False, shell=shell) is non-blocking on macOS but blocking on Windows—is due to differences in how the underlying operating systems handle process creation and input/output (I/O) management. Here's a detailed explanation:

1. Blocking vs Non-Blocking Behavior
   By default, subprocess.run() is a blocking call on both macOS and Windows. It waits for the process to finish before proceeding to the next line of code.

The key difference you're observing is likely tied to how subprocesses are handled with respect to the shell argument, especially on Windows vs macOS.

2. macOS Behavior
   On macOS, when you use shell=True, it uses the Bash shell (or whichever shell is specified in $SHELL). In many cases, shells like Bash or Zsh are implemented in a way that subprocesses are managed asynchronously, especially for commands involving redirection or pipelines.

Also, the shell process itself in Unix-like systems (including macOS) may fork subprocesses, and those subprocesses can run in the background, allowing Python to continue executing. This might give the appearance of being "non-blocking," even though it's still technically waiting for the subprocess to complete.

3. Windows Behavior
   On Windows, when shell=True, it uses cmd.exe as the shell. cmd.exe behaves differently compared to Unix shells. By default, Windows cmd tends to execute processes synchronously, meaning it will wait for the child process to finish before returning control to Python. This is why subprocess.run() would appear to be blocking here.

Additionally, cmd.exe handles processes and their I/O in a way that can cause the parent Python process to block until the child process exits.

4. Why Does subprocess.run Block?
   When subprocess.run() is invoked, it waits for the process to finish by default, regardless of whether you're using shell=True or shell=False. The blocking is inherent in subprocess.run() itself and isn't affected by the operating system directly.

The key factor is how the shell and subprocess are spawned and how output is handled by the system. On Unix-like systems (macOS), subprocesses may be handed off more efficiently to background tasks, whereas Windows tends to execute processes synchronously by default.

5. Possible Workaround
   If you want non-blocking behavior in both systems, you'd likely need to use subprocess.Popen() instead of subprocess.run(), as Popen allows for asynchronous management of processes."