[SOLVED] Changes when running Midi > Scripts?

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

Moderators: MattKingUSA, khz, spamatica

User avatar
oscillator
Established Member
Posts: 1127
Joined: Sat Jan 17, 2015 6:07 pm
Location: SWEDEN
Has thanked: 725 times
Been thanked: 296 times
Contact:

[SOLVED] Changes when running Midi > Scripts?

Post by oscillator »

I like the name change! :)

1. When running the Midi > Scripts, I remember that I used to get a dialog asking me if I wanted to apply the script to selected notes or to all. I don't get this anymore, so the script is applied to all notes. Is it possible to revert to the old behaviour?

2. To be able to run the scripts, you need to install python3-pyqt5
sudo apt-get install python3-pyqt5
I am not sure if this is new behavior, but the README should be updated:

Code: Select all

      - Python    The python scripting language
          http://www.python.org
          The remote control supports Python 2 or 3. See README.python.
          The bundled midi scripts ('Functions') require Python 3.
to

Code: Select all

      - Python    The python scripting language
          http://www.python.org
          The remote control supports Python 2 or 3. See README.python.
          The bundled midi scripts require Python 3 and python3-pyqt5.
Thanks!
Last edited by oscillator on Mon Nov 09, 2020 11:33 pm, edited 1 time in total.

MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik

kybos
Established Member
Posts: 97
Joined: Wed Oct 23, 2019 5:50 am
Been thanked: 3 times

Re: Changes when running Midi > Scripts?

Post by kybos »

1. You are right. But this was a "feature" of the duplicate menu, it never worked in the Midi->Scripts menu. It's not so easy to fix without the duplicate menu, so I will reinstate it for the time being and think about a better solution.

2. The behaviour is not new, at least I haven't changed anything.
I think it is mentioned there (couple of lines below your quote):
- PyQt5 is used by some of the bundled midi scripts ('Functions').
But it only mentions the "Functions" which is still a different thing than the "Plugins" (which is also ambivalent in this context) - now called Scripts.
User avatar
oscillator
Established Member
Posts: 1127
Joined: Sat Jan 17, 2015 6:07 pm
Location: SWEDEN
Has thanked: 725 times
Been thanked: 296 times
Contact:

Re: Changes when running Midi > Scripts?

Post by oscillator »

kybos wrote: Tue Oct 27, 2020 4:11 pm 1. You are right. But this was a "feature" of the duplicate menu, it never worked in the Midi->Scripts menu. It's not so easy to fix without the duplicate menu, so I will reinstate it for the time being and think about a better solution.
Thanks for answering and looking into it!

MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik

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

Re: Changes when running Midi > Scripts?

Post by Tim E. Real »

Ha! Coincidentally I noticed the other day that I think I made a mistake in the README,
which may cause confusion.

The 'Functions' menus are all C++ code, not Python. It's the Midi 'Plugins' that use Python.
So I believe the following should be corrected if I'm not mistaken:

"The bundled midi scripts ('Functions') require Python 3."
I think it should read:
"The bundled midi scripts ('Plugins') require Python 3."

"PyQt5 is used by some of the bundled midi scripts ('Functions')."
I think it should read:
"PyQt5 is used by some of the bundled midi scripts ('Plugins')"

@kybos If I'm not mistaken, if you get a chance can you correct it for me? Quite busy ATM.
Thanks.
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: Changes when running Midi > Scripts?

Post by Tim E. Real »

Oh, wait. I have not pulled for some days now.
You changed the name from 'Plugins' to 'Scripts'?

Well, whatever it's called now, if you can change the README would be great, thanks.
kybos
Established Member
Posts: 97
Joined: Wed Oct 23, 2019 5:50 am
Been thanked: 3 times

Re: Changes when running Midi > Scripts?

Post by kybos »

Sure, no problem.
I changed the README, fixed some other things there as well.
kybos
Established Member
Posts: 97
Joined: Wed Oct 23, 2019 5:50 am
Been thanked: 3 times

Re: Changes when running Midi > Scripts?

Post by kybos »

oscillator wrote: Tue Oct 27, 2020 5:11 pm
kybos wrote: Tue Oct 27, 2020 4:11 pm 1. You are right. But this was a "feature" of the duplicate menu, it never worked in the Midi->Scripts menu. It's not so easy to fix without the duplicate menu, so I will reinstate it for the time being and think about a better solution.
Thanks for answering and looking into it!
I can see that the Scripts menus in the Midi/Drum editors are not the problem. I would prefer to put them into the Function menu as a submenu, because there are already too many top menus and IMO they belong there semantically. But I also see that the easy accessibility is handy when heavily used.

The problem is the duplicate in MIDI->Plugins, which is in global scope. It looks exactly the same but the results are different and partly wrong. It only makes sense in the Arranger if at all, in other editors it leads to unexpected behaviour. So I moved it to the Arranger specific Functions menu and fixed some issues. Now it's applied to all selected midi parts in Arranger, or to the selected midi track (all parts of it), if no part is selected. There is a warning if nothing is selected.
User avatar
oscillator
Established Member
Posts: 1127
Joined: Sat Jan 17, 2015 6:07 pm
Location: SWEDEN
Has thanked: 725 times
Been thanked: 296 times
Contact:

Re: Changes when running Midi > Scripts?

Post by oscillator »

kybos wrote: Wed Oct 28, 2020 2:19 pm I can see that the Scripts menus in the Midi/Drum editors are not the problem. I would prefer to put them into the Function menu as a submenu, because there are already too many top menus and IMO they belong there semantically. But I also see that the easy accessibility is handy when heavily used.

The problem is the duplicate in MIDI->Plugins, which is in global scope. It looks exactly the same but the results are different and partly wrong. It only makes sense in the Arranger if at all, in other editors it leads to unexpected behaviour. So I moved it to the Arranger specific Functions menu and fixed some issues. Now it's applied to all selected midi parts in Arranger, or to the selected midi track (all parts of it), if no part is selected. There is a warning if nothing is selected.
I am happy that I can use the Midi>Scripts with the question about selection! For new users I think it is a bit confusing with MIDI>Scripts sometimes in a menu of its own, sometimes as a submenu. But then I only use the MIIDI>Scripts in the editors.

MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik

spamatica
Established Member
Posts: 573
Joined: Mon Feb 08, 2010 10:38 am
Has thanked: 80 times
Been thanked: 97 times

Re: Changes when running Midi > Scripts?

Post by spamatica »

kybos wrote: Wed Oct 28, 2020 2:19 pm The problem is the duplicate in MIDI->Plugins, which is in global scope. It looks exactly the same but the results are different and partly wrong. It only makes sense in the Arranger if at all, in other editors it leads to unexpected behaviour. So I moved it to the Arranger specific Functions menu and fixed some issues. Now it's applied to all selected midi parts in Arranger, or to the selected midi track (all parts of it), if no part is selected. There is a warning if nothing is selected.
Looks good!

Just to give a real world example of the usefulness in the arranger, I wanted to change the velocity of a kick drum on about 10 separate parts today. If I had been a bit quicker in mind I would have made a little python snippet and applied it to all parts at once. Instead of the very tedious and error prone process of drawing new velocity on all the kick hits.
MusE DAW
User avatar
oscillator
Established Member
Posts: 1127
Joined: Sat Jan 17, 2015 6:07 pm
Location: SWEDEN
Has thanked: 725 times
Been thanked: 296 times
Contact:

Re: Changes when running Midi > Scripts?

Post by oscillator »

spamatica wrote: Wed Oct 28, 2020 10:11 pm If I had been a bit quicker in mind I would have made a little python snippet and applied it to all parts at once. Instead of the very tedious and error prone process of drawing new velocity on all the kick hits.
I can see the usefulness of applying scripts to a lot of parts. I think I am going to investigate this more. I was thinking of writing a couple of new Python scripts to actually create MIDI note data, for example simple drum thythms, bass lines and arpeggios. Is the actual Python code of the scripts loaded into MusE at startup, or only the names of the scripts?

It would also be useful and cool to be able to run Python code typed directly into a text box, so you could do this w/o restarting MusE! :)

Anyway, I am happy you sorted this out @kybos so I/we can use it! Thanks!

MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik

kybos
Established Member
Posts: 97
Joined: Wed Oct 23, 2019 5:50 am
Been thanked: 3 times

Re: Changes when running Midi > Scripts?

Post by kybos »

oscillator wrote: Thu Oct 29, 2020 7:47 am It would also be useful and cool to be able to run Python code typed directly into a text box, so you could do this w/o restarting MusE! :)
That's certainly an interesting idea.
A simpler alternative could be to offer a refresh function for the Scripts menu, so you could create a new script in the user scripts folder as usual, then refresh the menu and it would be there, without the need for restart.
(If I remember right, the scripts are always loaded from disc on execution, so this would only be necessary for new scripts, not for modified ones.)
Tim E. Real
Established Member
Posts: 660
Joined: Sat Sep 15, 2012 12:36 am
Has thanked: 36 times
Been thanked: 105 times

Re: Changes when running Midi > Scripts?

Post by Tim E. Real »

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.

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.

@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')"

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).

Thanks!
kybos
Established Member
Posts: 97
Joined: Wed Oct 23, 2019 5:50 am
Been thanked: 3 times

Re: Changes when running Midi > Scripts?

Post by kybos »

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.
User avatar
oscillator
Established Member
Posts: 1127
Joined: Sat Jan 17, 2015 6:07 pm
Location: SWEDEN
Has thanked: 725 times
Been thanked: 296 times
Contact:

Re: Changes when running Midi > Scripts?

Post by oscillator »

kybos wrote: Thu Oct 29, 2020 9:08 am A simpler alternative could be to offer a refresh function for the Scripts menu, so you could create a new script in the user scripts folder as usual, then refresh the menu and it would be there, without the need for restart.
(If I remember right, the scripts are always loaded from disc on execution, so this would only be necessary for new scripts, not for modified ones.)
I'd love a refresh function.

If the scripts contents are loaded when they execute, I can go for a permanent "test"-script, that I can change in an external texteditor.

MusE DAW running on Debian 11 Testing/XFCE4.
https://oscillator.se/musik

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

Re: Changes when running Midi > Scripts?

Post by Tim E. Real »

Ooh, my mistake, sorry for the noise.
I think I saw that script document before but I don't recall seeing the flexibility of different languages.
Wow, MusE is pretty smart, eh?
Post Reply