Using _last_pointer_frame breaks when dragging to the left of the canvas, because we clamp
the value of the frame to >= 0. Motion would step once the pointer crossed the left edge
of the canvas because the frame value would always be zero.
This is not a problem when using the pointer x,y values which end up appropriately negative
under all conditions.
* ifdef unused static functions
* brackets around assignment and comparision
* no return statement in function returning non-void
* boost concept_checks.hpp unused-local-typedefs
This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
Fix initial read of discrete MIDI controllers.
Fix spurious note offs when starting to play in the middle of a note.
Faster search for initial event when cached iterator is invalid.
So much for dropping the cached iterator. The iterator is responsible for
handling note offs, so that doesn't work. This design means we have some stuck
note issues at the source read level, but they should be taken care of by the
state tracker anyway.
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.