SetProjectMarkerByIndex sometimes addresses wrong marker (FIXED)

[Meo-Ada Mespotine]

This is an odd issue:

When having multiple markers on the same position, SetProjectMarkerByIndex sometimes gets confused about which marker to address.

I made it happen with the following setup:

Add multiple markers with different names on position 30 secs in the project (A, B, C, etc).

Then I ran this code-line multiple times, which should change the name of the first marker found to Oops:

reaper.SetProjectMarkerByIndex(0, 1, false, 30, 0, 1, "Oops", 0)

Now what I would expect is, that running this multiple times changes the name of the first marker found to Oops once and leaving all others untouched.
However, sometimes, it "finds" different markers as first ones, so multiple markers get renamed. This is not always the case. Sometimes it works as expected for a long time and out of a sudden: boom.

It looks like Reaper treats multiple markers on the same position as equal, though they are not. And as Reaper sees them as equal, it seems to be, as if it changes the first marker found in memory or something, which might be Marker A or Marker B or Marker C, depending on what the memory does(though I might be wrong about this guess...).

I tried numerous workarounds but they all didn't work out.

I tried to code a Renumerate-Markers-function, where I go through all of them to give them a new shown-number, which worked, when I coded it initially. And suddenly, it stopped, skipping markers. After some bughunting, I found, that SetProjectMarkerByIndex is already the culprit.
Haven't checked SetProjectMarkerByIndex2.


Funny sidenote:
You can pass 0 as parameter isrgn. I made this parameter=0 instead of false and I initially thought, this is the bug. But it isn't.


Tested on Reaper 6.64x64 on Windows 7. Since you didn't change marker-stuff since then, I guess, the issue still persists.

PS: We need an "UpdateMarkerList"-function. I currently need to click into the markerlist or even the marker/region/takemarkers-visibility-checkboxes to see such changes when debugging scripts, which is possible but really tedious...


Edit: It's so frustrating, that it's not easy to reproduce. It sometimes happens for a minute or so and out of a sudden, everything is working fine. Some minutes later, the issue kicks in again.
All I could found, that running a defer-script for some time, doing the above code line, doesn't show the issue.
It seems like it's happening somehow at the initialization of Lua(?). As if Lua gets a list of markers to work with but it might change from creating an instance to the next creating an instance.

Like a table in Lua, whose elements aren't indexed. When you use pair on them, the order of the returned elements may change or be the same....

[Meo-Ada Mespotine]

My guess above, that the issue happens at Lua-init can't be true, as I had the issue with my renumerate-function. This repeatedly used the setprojectmarker-function after the enumprojectmarker-function.
So maybe when the internal markerlist gets updated, the order gets changed for markers on the same position.

But I can't figure out, why just sometimes but not always... -_-

[Meo-Ada Mespotine]

I think I could circumvent this problem, if I had a SetprojectmarkerByGuid-function, which works as the ByIndex-equivalent, but addresses the marker/region by guid.

[Meo-Ada Mespotine]

bump

[Meo-Ada Mespotine]

bumpy

[Justin]

hmm can you give steps to reproduce? or a script that demonstrates it by doing something 1000x?

The re-sorting of markers is stable, so if you have markers 1,2, and 3 all at the same time, in that order, editing any of them without changing the timing will preserve that order. Of course, if you change the marker ID then effectively you could change the order.

[Meo-Ada Mespotine]

Ok, I found a way to reproduce it:

The following code should create 10 markers at position 0 and renumerate their shown number, but some markers will be left out of the process, while others seem to be addressed and therefore set multiple times.
Worked the last few minutes...

-- first create markers at position 0, with name of countervariable i and shown-number=0
for i=0, 10 do
  reaper.AddProjectMarker(0, false, 0, 0, i, 0)
end

-- then try to go through all of them and renumerate their shown-number.
-- It fails and "leaves out" markers that stay 0, though I go through all of them.
for i=0, reaper.CountProjectMarkers(0) do
  A={reaper.EnumProjectMarkers3(0, i)}

  reaper.SetProjectMarkerByIndex(0, i, false, A[3], 0, i+1, "", 0)
end

Here's the almost same code-snippet which works. The only difference is, that the markers aren't created on position 0.

-- first create markers at position "i", with name of countervariable i and shown-number=0
for i=0, 10 do
  reaper.AddProjectMarker(0, false, i, 0, i, 0)
end

-- then try to go through all of them and renumerate their shown-number.
-- It fails and "leaves out" markers that stay 0, though I go through all of them.
for i=0, reaper.CountProjectMarkers(0) do
  A={reaper.EnumProjectMarkers3(0, i)}

  reaper.SetProjectMarkerByIndex(0, i, false, A[3], 0, i+1, "", 0)
end

[Justin]

ah sorry, I just realized I misread some code earlier -- the ordering of markers is defined by their position, but for markers of a given type (marker vs region) starting at the same time, then the markers are ordered by their ID number. So if you have two markers with the same ID number at the same time, and you increase the ID number of the first one, that one will get re-sorted to be the second one.

[Meo-Ada Mespotine]

Hmm, so renumerating the other way around, from the last to the first marker, would solve the problem?
The strategy we also use for deleting multiple markers?

[Justin]

Originally Posted by Meo-Ada Mespotine

Hmm, so renumerating the other way around, from the last to the first marker, would solve the problem?
The strategy we also use for deleting multiple markers?

well... no. it really depends on the changes being made. You can predict the index of a marker after changes are made. But it might be easiest to query the marker GUID using GetSetProjectInfo_String() before, then search the marker list to find the new index after.

(maybe we'll add a way to search by GUID for GetSetProjectInfo_String())

[Meo-Ada Mespotine]

Hmm, but the problem still persists, when I want to just change the shown number, I need to pass the other parameters as well.
I can get them using enumerate but when I set them, I don't just need to check, whether the marker I wanted to change, has been correctly changed, but also, if a wrongly changed marker hasn't "eaten up" attributes like name of the wrong marker.

I will make you a demo of the problem, as it's difficult to explain...but it basically is not just a problem of the marker that I want to set, but also the one the Setprojectmarker-function set by accident.

The only thing I can be sure to workaround it, is to store all marker-attributes in a table, delete all of them and then recreate them via the attributes I stored.
But then, I loose the guids, which I need in my project I work on for this.