Running a script on the Piano Roll takes way too long to respond

[lgmventura]

Describe the bug
Running a script from the scripts menu on the piano roll takes ages to respond. When you run a script such as humanize, it firstly asks if I want to run it only for selected notes or for all events in the track. When I confirm this, it takes like half a minute to display the dialogue and when I confirm on the dialogue, it takes another minute to run it on a single track. An equivalent feature runs nearly instantly in other pieces of software. Even the script "do nothing", which I guess is there for debugging, takes too long to respond.

To Reproduce
Steps to reproduce the behavior:

1. Import some MIDI file
2. Open one track on the piano roll
3. From the menu scripts, run a script for all note events in track or for a selection. I tested with humanize, do nothing and randomizeVelocityRelative.
4. MusE 4 freezes and it takes too long to respond.

Expected behavior
To respond nearly instantly. It should no more than running a loop over a couple of thousands of elements.

Desktop (please complete the following information):

• OS: Ubuntu 22.04
• Desktop MATE 1.26.0

Additional context
Machine: Acer Aspire V3 772G with 24 GB RAM installed
Intel i7 4th gen 2.2 GHz

[terminator356]

Tested with a small part with 20 notes:
Confirmed here.
The dialog opens quickly, but when execute is pressed it takes a long time to run.

For comparison, tested 'Reverse' script, it runs fast.
'Do nothing' also seems to run fast here, but maybe it is slow with a lot of notes.

Since 'Do nothing' does nothing except copy notes to the destination file, it suggests
that something is slow with the file opening, reading, and writing that is found in the scripts.

To be investigated more...

[spamatica]

I don't remember it going this slow. Even the DoNothing script takes it merry little time. I wonder if something os-wide has changed.
Not that scripts ever were particularily fast but this doesn't feel usable

[terminator356]

Weird. The scripts README says you can run -D for more info.
When I ran with -D everything was fast.
But even weirder, when I ran again without -D everything was still fast.

Now I cannot reproduce the problem at all.
We'll see what happens upon next re-boot...

I suspect something not with the scripts themselves but in the scripts.cpp file...

[terminator356]

Hi there. Very sorry for the long delay.

A quick update:
The extremely long script time is being caused by the code in Scripts::executeScript().
I have just examined the code and discovered the cause. I do not recall contributing to this code.

There may be hundreds or thousands of events to be processed.
But that itself is no problem.

For each event to be processed, song->applyOperation() is called once to delete the original event,
and then song->applyOperation() is called once again to add a new modified version of the event.

But unfortunately song->applyOperation() is an audio- synchronized function.
That means it waits for up to one complete audio cycle to execute.
That is for each event to be processed!
So if your audio system (Jack or MusE dummy driver) buffer size is say 512,
that is a whole lotta total time waiting for each midi event to be processed!

Conversely if your audio system buffer size is say 32, it should go much faster.

This was verified here a few minutes ago.
The solution is to gather up the events to be modified and call song->applyOperation()
only one time for the entire list of changes to be done.

This should be possible to fix, I believe...

[terminator356]

Done! In git master now.
Scripts run much faster now. Tested with audio buffer size 2048. No problems.
Tested undo/redo of scripts OK.
Try it if you can. Let me know if any trouble.
Thanks.

[luzpaz]

How to test ?