Tempo changes and the TempoMap / TempoMap::tick2time()

I am attempting to convert ChordRest.tick() into elapsed milliseconds (for the score, the number of milliseconds up to the point where the current ChordRest starts playback). First, I am not getting the results I expect when using TempoMap::tick2time(), and I'm not understanding the inner workings of its various overloaded flavors. Basically, I am not fully grasping how to use the Score's TempoMap (_tempomap internally).

Here is what I think I understand:
- I see that in the TempoMap: key = tick, value = TEvent.
- Tempo is in Beats per Second (BMP/60)
- I imagine that in practical terms, the most granular level at which a user will apply a tempo change is a ChordRest. But the map is by tick, so a tempo change might occur at any tick in the score.
- I imagine that, given tempo changes anywhere, correctly calculating elapsed time involves an incrementing counter, incrementing for each new ChordRest.tick() (the starting tick for the ChordRest), keeping track of the elapsed time prior to the current ChordRest. This requires iterating over all the ChordRests in the score in playback order, from the beginning of the score.

Here are some of my questions:
- Do I need to do a whole separate loop where I iterate over the TEvents in the score's TempoMap from start to end? Or can I rely on tempo changes only occurring on the same tick as a ChordRest, and check the tempo map at each of my ChordRest.tick() values?
- If a ChordRest's start tick is delayed in playback because of Swing, is the tempo change applied to that ChordRest also delayed the same number of ticks?

I think that's it. If TempoMap::tick2time() really provides the elapsed time value I'm looking for (I can convert from qreal to int and seconds to milliseconds), please let me know how to use it properly.

Thanks in advance...