New! Restored Python remote control

MusE is a DAW for Linux with both MIDI and Audio editing. https://muse-sequencer.github.io

Moderators: MattKingUSA, khz, spamatica

Post Reply
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

New! Restored Python remote control

Post by Tim E. Real »

10 years ago the ability to control MusE remotely via python was added,
as an experimental cmake option.
But it fell by the wayside and would not compile.

For further info and commands (until I add a proper README) please see the bottom here:
http://www.muse-sequencer.org/index.php ... nformation

Note also that Pyro will not work with a host name that resolve to loopback address 127.0.0.1
So be sure your box's name and address is OK.

Working very hard to fix the Python3 bug... You'll want Python2 for now. See below.

From the ChangeLog:

Code: Select all

      * New! Restored Python remote control:
      - Completely updated to Pyro4.
      - Compiles with Python 2 or 3.
      - The API, the launcher, and ALL examples have been updated.
      - Enabled with a cmake option and -y command line option, as before.
      - BONUS: Either works with an ALREADY running Pyro NS, or else starts it.
      - CAVEAT: A bug is preventing it from working with Python3: It refuses
         to recognize any attributes in the muse module. Even if Python3 is installed
         you can force MusE to use Python2, with cmake flags for the include path and lib.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: New! Restored Python remote control

Post by Tim E. Real »

OK The Python 3 bug is fixed. In git master now.
The remote control supports Python 2 and 3 !

For details and a list of commands, a new README.python was added.
And the main README was updated.

It's pretty straight forward to get running.
There are examples.
Think of it, control over a network with easy scripts, 'live' as MusE runs.

Ask if you'd like to see an commands added.

Tim.
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: New! Restored Python remote control

Post by Tim E. Real »

Updates in git master now:
OK, ignore what I said about host name and loopback address 127.0.0.1.
Now it will work just fine with defaults, locally.
If you want to talk to another machine, set a 'real' address.
You can use the new MusE command line settings shown below.

From ChangeLog:

Code: Select all

      * Command line complete redesign using QCommandLineParser:
        Supports long options. Qt text translations enabled.
        Cross-platform, no getopt used.
      * Python remote control redesign:
        Uses QThread instead of pthreads to start/stop the Pyro server.
        Launcher python code simplified. No custom event loop.
        Uses daemon loopCondition to cleanly shutdown.
        New MusE command line options for the python bridge:
        --pyro-ns-host<host>  --pyro-ns-port<port>
        --pyro-daemon-host=<host> --pyro-daemon-port<port>
        --pyro-comm-timeout<time (s)>

Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: New! Restored Python remote control

Post by Tim E. Real »

Some thoughts about the experience:

I learned that Python is normally a single global interpreter - you normally (see below) cannot
run two python scripts in the same thread or even the same process.

This presented a real head-scratching problem: We run our Pyro server code in a Python script.
Start 'er up and off she goes into her very own event loop world, never to come out again.
How to stop the server loop then, and do a clean exit so that the QThread running it doesn't complain
and then we must ungracefully terminate it?

* Here is one way to shut down the server:
While the server is running its Python script, we must execute another Python script to shut the server down.
This other script is very simple, it gets a proxy to the muse object and simply executes a
special 'shutdown' function which I have included in the MusE Python class.
Which then simply executes daemon.shutdown(). (Got that from an example.)
No ip addresses or ports required are required in this script, or any other example script.
That's the beauty of Pyro's Proxy feature !
It works! You can shut down the server simply by running the shutdown script form say, a new terminal.

OK so we could simply do that in a new QProcess from our code.
But... that's kinda brutal. Much nicer if we could do it in another thread or even the same thread !

But Python is tied up running our server script!
How do we run another script from the same or even a different thread?

The answer is Python sub-interpreters. Supported since 1997 !
It's... detailed. I decided not to go near it. Maybe at some point. Interesting stuff.

* Another way to shut down the server is by making a custom event loop, as seen in the eventoop example.
I tried this (it was in the first commit) but the problem is it required a broadcast server (not 127.0.0.1) for the 'select' function.
It says so in the example. I couldn't figure out how to have a loop without the 'selectable' broadcast server.

* Another way to shut down the server is with Pyro's daemon loopCondition feature,
which can be used to break out of the daemon loop and provide a clean shutdown.

I used that technique.
But the technique required (as documented) fiddling with the Pyro config.COMMTIMEOUT option.
I have put the timeout at 5 seconds by default.
There is a new MusE option --pyro-comm-timeout for that in case adjustment is needed.

See the new README.python for more details.
Tim.
Post Reply