Lua code for quickly getting a track by GUID

[Justin]

I just wrote this, maybe someone will find it useful:

local track_guid_cache = {};

function track_from_guid_str(proj, g)
  local c = track_guid_cache[g];
  if c ~= nil and reaper.GetTrack(proj,c.idx) == c.ptr then
    -- cached!
    return c.ptr;
  end
  
  -- find guid in project
  local x = 0
  while true do
    local t = reaper.GetTrack(proj,x)
    if t == nil then
      -- not found in project, remove from cache and return error
      if c ~= nil then track_guid_cache[g] = nil end
      return nil
    end
    if g == reaper.GetTrackGUID(t) then
      -- found, add to cache
      track_guid_cache[g] = { idx = x, ptr = t }
      return t
    end
    x = x + 1
  end
end

[Ivannn Bennnettt]

Thank you Do you like write in Lua?

[X-Raym]

Thx, but we already have

reaper.BR_GetMediaTrackByGUID( proj, guidStringIn )

in SWS extension :P

[lb0]

Originally Posted by X-Raym

Thx, but we already have

reaper.BR_GetMediaTrackByGUID( proj, guidStringIn )

in SWS extension :P

Yes - but the reaper.BR_GetMediaTrackByGUID code does not cache anything - and brute forces the search through all tracks every time you call it.

Justin's version builds a cache of the GUIDs - so any subsequent searches will return quickly by using a lookup table if the track has already been cached.

So much quicker probably. I use this sort of method frequently as a lookup table is usually much quicker when you need to repeatedly perform a task.

Thanks Justin.

[X-Raym]

So much quicker probably. I use this sort of method frequently as a lookup table is usually much quicker when you need to repeatedly perform a task.

Oh yes sure it is a useful trick :P


Cache results is fine if the script doesnt insert or remove tracks.

[heda]

Thank you Justin

[Lokasenna]

Unless I'm missing something this will only cache the track you're looking for, which rather defeats the purpose of a cache.

I think the last bit should be:

    local guid = reaper.GetTrackGUID(t)
    -- add to cache
    track_guid_cache[guid] = { idx = x, ptr = t }
    if g == guid then
      -- found      
      return t
    end

Originally Posted by X-Raym

Cache results is fine if the script doesnt insert or remove tracks.

Also this. Does the cache need to store the track's index if you're already storing the pointer?

[Justin]

Originally Posted by Lokasenna

Unless I'm missing something this will only cache the track you're looking for, which rather defeats the purpose of a cache.

It just means that the first time you ask for a track-by-GUID, it will be O(N) to find the track, but every subsequent time it will be O(1) (or log(N) if that's how lua's table's are implemented).

Adding all of the tracks to the cache on a miss would help if you are planning to access all tracks immediately (with worse performance if you're just looking for a couple of tracks, since building the table isn't free -- I haven't looked, are inserting into Lua tables O(N) or O(log(N)))?

Cache results is fine if the script doesnt insert or remove tracks.

Also this. Does the cache need to store the track's index if you're already storing the pointer?

Yes! It stores the index so it can quickly detect whether the cache is still valid for the track GUID in question.

[Lokasenna]

Originally Posted by Justin

It just means that the first time you ask for a track-by-GUID, it will be O(N) to find the track, but every subsequent time it will be O(1) (or log(N) if that's how lua's table's are implemented).

Adding all of the tracks to the cache on a miss would help if you are planning to access all tracks immediately (with worse performance if you're just looking for a couple of tracks, since building the table isn't free

You already have to get the track and GUID for N tracks - putting them in the table would add another operation or two, but I'd be interested to know if it's a significant cost compared to two global table lookups and API calls.

I haven't looked, are inserting into Lua tables O(N) or O(log(N)))?

Not sure. There are some details of how tables are handled on the fifth page (labelled p.19) here: https://www.lua.org/gems/sample.pdf

Yes! It stores the index so it can quickly detect whether the cache is still valid for the track GUID in question.

Interesting. My understanding is that a track's GUID will never change, while I imagine the MediaTrack pointer is only valid while the project is open and would be different the next time you load it.

Your code looks to me like it's just checking if the pointer still refers to track 5 as a basis for invalidation - does moving tracks around change their pointer?

[Justin]

Originally Posted by Lokasenna

You already have to get the track and GUID for N tracks - putting them in the table would add another operation or two, but I'd be interested to know if it's a significant cost compared to two global table lookups and API calls.

For the original use case (a control surface plug-in), the caller would usually only get a dozen or so tracks-from-GUID, for which this code is pretty efficient. If you're often going to be getting all tracks from their GUIDs, it would likely be faster to build a full table of GUID->tracks.

Interesting. My understanding is that a track's GUID will never change, while I imagine the MediaTrack pointer is only valid while the project is open and would be different the next time you load it.

Your code looks to me like it's just checking if the pointer still refers to track 5 as a basis for invalidation - does moving tracks around change their pointer?

Tracks could cease to exist. Checking if the pointer matches is a quick way to detect if the track still exists. If it no longer exists, or the tracks were reordered, the pointer will differ, and the cache can be rebuilt.

That code could handle things even more safely by checking to make sure the pointers match, and also checking to make sure the GUID match.

Here's a more aggressively-safe version (just adds "and reaper.GetTrackGUID(c.ptr) == g"):

local track_guid_cache = {};

function track_from_guid_str(proj, g)
  local c = track_guid_cache[g];
  if c ~= nil and reaper.GetTrack(proj,c.idx) == c.ptr and reaper.GetTrackGUID(c.ptr) == g then
    -- cached!
    return c.ptr;
  end
  
  -- find guid in project
  local x = 0
  while true do
    local t = reaper.GetTrack(proj,x)
    if t == nil then
      -- not found in project, remove from cache and return error
      if c ~= nil then track_guid_cache[g] = nil end
      return nil
    end
    if g == reaper.GetTrackGUID(t) then
      -- found, add to cache
      track_guid_cache[g] = { idx = x, ptr = t }
      return t
    end
    x = x + 1
  end
end

[schwa]

Originally Posted by Lokasenna

Not sure. There are some details of how tables are handled on the fifth page (labelled p.19) here: https://www.lua.org/gems/sample.pdf

Pretty interesting When Lua is doing its job right, inserting into an array is O(1), although by design it won't (can't) do its job right all the time. I get the impression Lua started life as a clever hash function.