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]

Will test further. As I said, it happens very randomly and made me nuts, when trying to debug some of my marker-functions.

The ID might be a starting point, so maybe that could be it(will test it).

But as I said, having a Set-function working on marker-guid instead of any number would solve the problem for me 100%.

One thing I forgot to mention, I haven't seen the problematic behavior with the Enum-function, only with the Set-function.

Edit: now that I think about it, I had the most issues, when doing renumerate over the shown-number of markers. Some simply were skipped due this leading to doubled numbers, whereas it should have been 1 2 3 4 5... n not 1 2 2 3 4 6 5 6 7... n and such.

[Justin]

Perhaps you can make a wrapper that enumerates the marker first to make sure it's the right one, or something?

(and asserts if something's awry, which would give some extra info?)

[Meo-Ada Mespotine]

I've tried it but it's becoming a mess really quickly.

The problem is, that I can get, if the enumerated marker is the right one, but when I address the same marker with set, I can not be sure, that I'm addressing the correct one.

So I can get, if a marker is set wrong, but there's no guarantee that I can set it right.

So even if I check it, I still have trouble to correct it.

I could move markers around so they aren't in the same place, like

1. storing all marker-guids in their order into a table
2. putting markers from the same position to the end of the project, one by one with
3. getting, which guid the last marker now has and set their shown-number in the order stored in my guid-table, then
4. restore their position.

This is really ugly and, to be honest, I think that the order used by SetProjectMarker should rather be guaranteed and not be dependent on a sophisticated algorithms.
And the one I described above would work on my renumerate function, but might not work in other usecases, so I would need to develop another sophisticated workaround for the other one as well...

[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.

[Justin]

Hmm.

Let's make some assertions. For one, this will never change the order of markers and will only modify the name:

ok, isrgn, pos, endpos, name, num, color = reaper.EnumProjectMarkers3(0, i)
if ok then reaper.SetProjectMarkerByIndex2(0,i,isrgn,pos, endpos, num, name .. " changed", color, 0) end

Now, let's change the position:

ok, isrgn, pos, endpos, name, num, color = reaper.EnumProjectMarkers3(0, i)
if ok then reaper.SetProjectMarkerByIndex2(0,i,isrgn,pos + offset, endpos, num, name .. " changed", color, 0) end

The marker order could change AFTER the call to SetProjectMarkerByIndex2(). So subsequent accesses of this marker would need to search by GUID, or predict how it would change with a more complex heuristic.


Changing just the marker number:

ok, isrgn, pos, endpos, name, num, color = reaper.EnumProjectMarkers3(0, i)
if ok then reaper.SetProjectMarkerByIndex2(0,i,isrgn,pos, endpos, new_num, name .. " changed", color, 0) end

If are multiple markers at "pos", then the marker order could change AFTER the call to SetProjectMarkerByIndex2().

Note that if you're doing this inside a loop, and the index changes, it will also mean that the other markers whose indices are between the old and new indices will also change.

If you want to process each marker exactly once, perhaps enumerate all markers by GUID, save those GUIDs, then go through each marker finding it by GUID and processing it.

Hope that helps!

[Justin]

Perhaps we could make SetProjectMarkerByIndex2() have a flag which means "don't re-sort", then you could make all the changes, and request a re-sort.

[Justin]

alternatively:

- if you are only possibly increasing pos, number, then processing the list right to left would be safe
- if you are only possibly decreasing pos, number, then processing the list left to right would be safe

[Meo-Ada Mespotine]

Perhaps we could make SetProjectMarkerByIndex2() have a flag which means "don't re-sort", then you could make all the changes, and request a re-sort.

That would be fantastic...

- if you are only possibly increasing pos, number, then processing the list right to left would be safe
- if you are only possibly decreasing pos, number, then processing the list left to right would be safe

If I got it right, this could potentially cause trouble with markers, who have that exact position.
So if I have three markers at position

0.0000000
0.0000000
0.0000001

and I increase the second one, I would just move the problem to the next marker:

0.0000000
0.0000001
0.0000001

So I still have the same problem.


Thanks fore your code-snippets. Will go through them but right now, my brain hurts from thinking too much about it XD

If anything else fails,

1) I will save all attributes of all markers including guid in a table and sort them in there,
2) then move all markers to the end of the project, but that they are one second apart, and
3) restoring their position one by one, depending on their guid, and giving them this way their respective shown-nrs but that would be an ugly hack...

Edit:
I would use the action "Markers: Renumber all markers in timeline order" but I need full control over renumbering regions or just markers and the timerange.
Bummer, as this renumerates perfectly...

[Meo-Ada Mespotine]

Ok, after some more thought, a don't sort-flag seems to be the best idea.
I did some more tests to see if some of my other concerns apply, but it didn't, so yeah, if you would implement such a flag, the problem should be solved 100%.

Thanks for going into the details of the problem, I really appreciate that you took the time for it

[Meo-Ada Mespotine]

Solved with latest rc