There are still problems because actions like trim_front()
that use the edit point get the edit point with different
results than the code that sensitizes actions
snap now fills in a struct (MusicFrame) which contins a snapped frame
along with a music divisor.
this gives useful information wrt magnetic snap which may or may not
have rounded to an exact musical position.
region position may now be set musically (using quarter notes for now).
this patch fixes several problems in the current code:
- dragging a list of music-locked regions now maintains correct
musical offsets within the list.
- splitting regions using magnetic snap works correctly (#7192)
- cut drag should now work correctly with magnetic snap.
- musical length of split midi regions is no longer frame based.
This allows common keyboard shortcuts from any Tab (Editor, Mixer).
Discuss: should those actions/methods also be moved to ArdourUI instead of
PublicEditor?
- for those not in the know, this series provides a way to
remove the temporal distortion introduced when using an
audio frame-based gui for music-locked objects.
In short, the gui uses an audio frame representation to move
objects. It displays the object using frame_at_beat(), quantizing
the time value to audio frames. This is fine until the user selects
that frame but expects it to be interpreted as a beat.
Thus beat_at_frame() would not produce the user-expected beat
(temporal quantization error of up to 0.5 audio samples).
This is one method of mapping audio time to music time accurately.
This functor/closure is responsible for stealing focus from any existing text entry (or whatever else may have focus)
when clicking on a CairoWidget or derived class.
The old implementation just gave focus back to the editor canvas. The new version walks up the widget packing
heirarchy to find a focusable parent (from the CairoWidget for which it is invoked). If no focusable parent
is found, it cancels keyboard focus in the toplevel window containing the CairoWidget
I would have loved to split this apart, but there are just so many interrelated changes,
it makes little sense and would be a huge effort that would break future git bisect
use because so many intermediate commits would not compile
