Tim E. Real wrote: ↑Thu Oct 29, 2020 11:22 pm
Oscillator's idea may be more of a candidate for MusE's remote python scripting feature.
Users would not be familiar with how to access MusE variables and structures via the built-in scripts,
whereas the remote feature has documented 'well protected' commands.
See the README.python.
Once it is set up and running, you can write a script in your favourite editor and then run it, even remotely over a network.
The remote python feature seems to have quite a different purpose, more high level. I don't see a possibility to edit midi events with it.
The bundled and user created midi scripts that are meant here are also documented, if I see it right:
https://github.com/muse-sequencer/muse/ ... ile-format
I agree that whether we are talking about the built-in scripts or the remote feature, it might be worth expanding
on the ideas, to allow the user's scripts to populate some menu for easy access.
Maybe provide a handy built-in text editor (what about python highlighting?) for quickly running and testing scripts.
Would be nice to have, but I think it's still quite easy (and perhaps even better) to create a script in the /scripts home folder, edit it in an external full-featured editor and execute from the Scripts menu.
@kybos Another wee favour to ask: In README.python I have
"Once Python and Pyro have been installed, support them by setting this MusE cmake option to 'ON':
ENABLE_PYTHON (Default is 'OFF')"
But recently I enabled it by default, because it has been overhauled, modernized, and thoroughly tested.
So perhaps the text should read:
"Once Python and Pyro have been installed, support them by checking that this MusE cmake option is set to 'ON':
ENABLE_PYTHON (Default is 'ON')"
Done, I fixed it in the wiki:
https://github.com/muse-sequencer/muse/ ... te-control
I cleaned up the obsolete READMEs too (those available in the wiki now), so there is no confusion and duplicate efforts.
One final note, I do not check in the top cmake file to distinguish between python 2 and 3, instead simply whether python >= 2.4 is available.
The remote feature works with either python 2 or 3, but the built-in scripts require python 3.
Thus if the user has python 2 installed but then tries to run the built-in scripts, I believe an error will occur.
So at some point we should try to distinguish what python version is installed and warn that they need python 3 for the built-in scripts.
Also, there's a TODO in the top cmake file about checking whether Pyro4 is installed (required for the remote feature).
I suggest we remove python 2 completely. It's obsolete and no longer maintained anyway.