I am not precisely sure why the cached iterator was causing this problem, it
shouldn't be invalidated, and the times make sense. It may be some lock
related issue since the iterator holds a lock on the source.
In any case, this cached iterator was just to avoid repeated linear search of
the model, but since the model has a logarithmic search, instead just scrap all
this problematic persistent state and search for the appropriate start time
every read. No need to be careful about invalidating when anything changes.
cursor icons squared with north-west gravity.
hotspots are identical to original icons.
otherwise gdkcursor-win32 creates square cursors with
center gravity and hotspot X/Y differs.
Fix some inaccurate/misleading comments that led to said bug.
Gracefully handle the "impossible" case where we can't figure out a state ID
for an automation track, instead of crashing.
The idea here is to do the reasonable thing, and copy objects of some
type (e.g. MIDI region, gain line) to tracks with a matching type. The user
can override this with a track selection, which will be used straight-up.
Lost: ability to copy/paste lines across types, e.g. gain to pan. This is
often questionable, but sometimes useful, so we will need to implement some
sort of "greedy mode" to make it possible. Implementation simple, but not sure
what to do. Perhaps this should only be possible if one automation track is
explicitly (i.e. via track selection) involved, and the types are at least
compatible-ish?
This should probably hijack the same modifier as the guard points and work the
same on all automation tracks, but I did it this way to not change behaviour of
track automation where a default is much more reasonable.
