Pretty small bug, but probably easy to fix too!
I noticed while experimenting with tempo events that if I select multiple tempo events and delete them, the ones that are deleted are not the ones that I intended.
This is easier to show with an example. If the events are:
I get the following behaviors:
(1) I select "Tempo 1", then "Tempo 2", and delete both. In this case I am left with Tempo 3 and Tempo 4 (EXPECTED BEHAVIOR).
(2) I select "Tempo 2", then "Tempo 1", and delete both. In this case I am left with Tempo 2 and Tempo 4
While I don't know the Rosegarden code base, I'm pretty sure I've written this exact bug myself. I am guessing that the selections go in a list of indexes in reverse order (for (2) this would be [0, 1]
). Rosegarden then iterates this list, deleting entries by index as it goes. So first it deletes entry 0, which is "Tempo 1". Then it deletes entry 1 -- but because "Tempo 1" is gone, entry 1 now points at "Tempo 3". (my guess could be a bit off -- maybe the list is in order of selection, but Rosegarden repeatedly pops indexes to delete off the end)
I checked, and doing this to the last entry in the list does NOT cause an immediate crash. As I believe Rosegarden is a C++ program, it's possible I just got lucky and corrupted some unimportant memory.
Your analysis is absolutely correct !!
I have made a fix - see merge request.
Looks good. Merged as [ee8a8c]. Please test latest git.
Related
Commit: [ee8a8c]