How's that for an awkward title?
The script I'm working on involves a) a bunch of tracks, b) a whole bunch of items, and c) a shitload of stretch markers. As a result, I've discovered that the ReaScript item functions, and especially the stretch marker functions, take more and more time as you get "deeper" into a project.
Take, for instance, a set of drum recordings - twelve tracks in all. We've used Dynamic Split to add stretch markers, moved them around, and run
SWS/BR: Split selected items at stretch markers. Currently, each of our drum tracks has just over 300 items.
Splitting a track-length item with a few hundred markers, I discovered, keeps all of the markers for each of the resulting items, so we have to get rid of them before the script can do its real work. Easy enough - get the take, number of markers, iterate through them and see if they're within the bounds, delete them if they aren't.
Code:
function DS.crop_stretch_markers_to_visible(take)
local num_markers = reaper.GetTakeNumStretchMarkers(take)
local length = reaper.GetMediaItemInfo_Value( reaper.GetMediaItemTake_Item(take), "D_LENGTH")
for i = num_markers - 1, 0, -1 do
local ret, pos, src = reaper.GetTakeStretchMarker(take, i)
-- Reaper's rounding sometimes puts a marker at the end of an item, but *just* outside it
if pos < 0 or (pos > length and (length / pos < 0.999)) then
reaper.DeleteTakeStretchMarkers(take, i, nil)
end
end
end
However, this function starts taking a long time as I get further down the track list - everything to do with items does, but this one takes about 20 times as long as the rest of my processing combined so the time increase is particularly noticeable here.
Processing time comparison:
https://www.dropbox.com/s/lvpwlllshg...aling.pdf?dl=0
The tracks are identical as far as items, markers, splits, etc. The only difference is track number.
(As far as I can tell, the item's position in a given track doesn't matter - the first items are processed in roughly the same time as the last).
Cheers.