Previously only manual changes of the note-range using the scroomer.
The NoteRangeChanged() was ignored for implicit changes (e.g. while
recording, step-entry) and automatic-fit that didn't involve a drag
event.
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
Since 478f26b2ad, transport_rolling() is only true when actually rolling.
Count-in is a no-roll process (don't move playhead, no playhead UI
position interpolation 55b8b448).
But transport isn't exactly stopped either (preparing to roll), so
during count-in transport_stopped() == transport_rolling() == false.
Note lines on a MIDI-track were able to exceed the time-axis' height
towards the top. If a MIDI track was at the top, the TAV's canvas-group
would increase the overall bounding-box of the track-area and allow
tracks to visually bleed into the time markers group.
- 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.
I am not sure what causes this, but it can happen when finishing a record
sometimes. Probably MidiSource::_writing isn't updated in the right order with
whatever triggers the redisplay, but at least not crashing is better...
Remove Canvas::Layout, use Canvas::Container for the same purpose, move child-rendering into Item::render_children() so that it
could theoretically be used by any derived type.
We really need some kind of more sophisticated assert macro that can be
switched to non-fatal logging mode for release builds. A log message, which is
often all that would happen, is a lot better than a trainwrecked performance...
git-svn-id: svn://localhost/ardour2/branches/3.0@13892 d708f5d6-7413-0410-9779-e7cbd77b26cf
It's slightly possible that this causes trivial build failures on different
configurations, but otherwise shouldn't cause any problems (i.e. no actual
changes other than include/naming/namespace stuff). I deliberately avoided
removing libardour-config.h since this can mysteriously break things, though a
few of those do seem to be unnecessary.
This commit only targets includes of ardour/*.h. There is also a very large
number of unnecessary includes of stuff in gtk2_ardour; tackling that should
also give a big improvement in build time when things are modified.
git-svn-id: svn://localhost/ardour2/branches/3.0@12420 d708f5d6-7413-0410-9779-e7cbd77b26cf
