Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 06-22-2017, 05:28 AM   #1
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default MIDI editor: Recent versions get unnecessarily bogged down if multiple takes visible

REAPER is renowned for its highly efficient and optimized audio engine. I hope that the same skills will be applied to the MIDI editor.

REAPER gets *unnecessarily* bogged down when multiple takes are visible or editable in the MIDI editor, and it seems to be getting worse and worse in recent versions.

I compared the speeds of versions 5.00 to 5.40, using the following simple script:
Code:
local take = reaper.MIDIEditor_GetTake(reaper.MIDIEditor_GetActive())
local prevTime, currentTime = 0, reaper.time_precise()
local n = 0 -- Count number of cycles
tCycleTimes = {} -- Table to store the time taken for each cycle

local maxCycles = 10

function testDeferSpeed()
    prevTime = currentTime
    currentTime = reaper.time_precise()
    n = n + 1
    tCycleTimes[n] = currentTime - prevTime
    reaper.MIDI_InsertCC(take, true, false, n, 0xB0, 0, 1, 100)
    if n >= maxCycles then
        return 
    else
        reaper.defer(testDeferSpeed)
    end
end

reaper.defer(testDeferSpeed)
The script makes a small MIDI edit to the active take in each defer cycle, and then measures the time between each defer cycle.

Results:

If I only have the active track visible/editable in the MIDI editor, and I run the test script, each defer cycle only takes a few hundredths of a second, as expected.

However, if I make several large takes visible in a single MIDI editor (for example, 15min orchestral tracks with lots of CCs), each defer cycle takes almost 1.5 seconds!

Strangely, this even happens when none of these large takes have any visible MIDI in either the editor or the arrange view. For example, if these takes only start at measure 10, and both the MIDI editor and the arrange view are zoomed in to measures 1-5 (i.e. only the active take overlaps the zoom areas), the defer cycles are still as slow!

The MIDI editor should be optimized so that
* Takes that haven't been changed, should not be re-analyzed, and only mimimal re-drawing of the MIDI data should performed, if any MIDI data is visible in the editor.
* Takes that have no MIDI data visible in the MIDI editor, should not have any effect on the MIDI editor's responsiveness.

And it gets even stranger... Older versions of REAPER are much, much faster: When I tested the same project in versions 5.00 to 5.40, I got the following average times:
v5.00: 0.42s per defer cycle
v5.10: 0.44s
v5.20: 0.61s
v5.30: 0.98s
v5.40: 1.43s

v5.40 is more than three times slower than v5.00!

Last edited by juliansader; 07-23-2017 at 03:44 AM.
juliansader is offline   Reply With Quote
Old 06-22-2017, 04:07 PM   #2
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

The deeper I investigate, the more worrisome results I get:

Having multiple takes per item bogs down the MIDI editor even worse -- even though only one take per item can be seen or edited in the editor. Having two takes in each item that is visible in the MIDI editor *doubles* the defer cycle time, and having three takes *triples* the cycle time.

Since the non-active takes in multi-take items are not available for editing in the editor, and their MIDI data is not displayed, the number of takes per item should have negligible effect on the responsiveness of the MIDI editor.
juliansader is offline   Reply With Quote
Old 11-08-2017, 07:23 PM   #3
_Stevie_
Human being with feelings
 
_Stevie_'s Avatar
 
Join Date: Oct 2017
Location: Black Forest
Posts: 5,054
Default

Is that the reason, why you use MIDI_SetAllEvts instead of MIDI_InsertCC?
_Stevie_ is online now   Reply With Quote
Old 11-09-2017, 11:14 AM   #4
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Quote:
Originally Posted by _Stevie_ View Post
Is that the reason, why you use MIDI_SetAllEvts instead of MIDI_InsertCC?
Alas, this problem seems to affect all deferred MIDI scripts, even if they use MIDI_SetAllEvts.
juliansader is offline   Reply With Quote
Old 05-27-2018, 02:43 AM   #5
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Given that another MIDI editor slowdown bug was fixed in v5.90, I hope that this is a good time to bump this thread.

Quote:
Originally Posted by Edgemeal View Post
v5.90 - May 24 2018
+ MIDI editor: avoid double-drawing many updates
+ MIDI editor: faster updating when using hand scrolling
Other threads related to deferred scripts and MIDI editor sluggishness:
* Reascript: New function MIDIEditor_Update for faster MIDI scripts
* Reascript: Restore original behavior of PreventUIRefresh to make deferred scripts run faster

Last edited by juliansader; 05-27-2018 at 02:51 AM.
juliansader is offline   Reply With Quote
Old 06-18-2018, 05:15 AM   #6
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Is this only affected when there are multiple takes open or is it also sluggish with multiple items selected in the midi editor?
srdmusic is offline   Reply With Quote
Old 06-18-2018, 09:27 AM   #7
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Quote:
Originally Posted by srdmusic View Post
Is this only affected when there are multiple takes open or is it also sluggish with multiple items selected in the midi editor?
* By "open", do you mean visible or editable in a MIDI editor?

* I haven't checked the effect of selection itself. However, if selection is linked to visibility or editability, it should have the effects described above.
juliansader is offline   Reply With Quote
Old 06-18-2018, 12:49 PM   #8
srdmusic
Human being with feelings
 
Join Date: Dec 2016
Posts: 876
Default

Quote:
Originally Posted by juliansader View Post
* By "open", do you mean visible or editable in a MIDI editor?

* I haven't checked the effect of selection itself. However, if selection is linked to visibility or editability, it should have the effects described above.
Yes, I mean open and visable in the midi editor. I'll test your script to see what the result is. I have noticed a significant drop in preformance in the midi editor since 5.7.
srdmusic is offline   Reply With Quote
Old 03-28-2019, 07:56 AM   #9
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Hmm can you send (to support) a large MIDI project (and reaper.ini probably) that uses no plug-ins that demonstrates the slowdown?
Justin is offline   Reply With Quote
Old 03-29-2019, 06:28 AM   #10
juliansader
Human being with feelings
 
Join Date: Jul 2009
Posts: 3,714
Default

Quote:
Originally Posted by Justin View Post
Hmm can you send (to support) a large MIDI project (and reaper.ini probably) that uses no plug-ins that demonstrates the slowdown?
Are you replying to the issue that I described in first posts, or to srdmusic's post?
juliansader is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 03:23 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.