This note-mode had no effect on anything at all, at least as far back
as 5.12. There is a note-mode in the GUI which affects the duration of notes
added using the GUI, and that remains in place. It is not clear
if the _percussive member of Evoral::Sequence ever had any effect on
the actual MIDI event stream the Sequence could generate.
If queue_draw is "frozen", we simply accumulate drawing
requests in a (union) rectangle, and when finally "thawed"
the canvas submits a single redraw request for the entire
accumulated rect.
Although in theory this is all that GTK/GDK does for
draw requests, callgrind reveals significant costs
associated with the actual calltree for GtkWidget::queue_draw_area().
One potential cost is that GDK also maintains a list of
invalidated rectangles in addition to the union, and
for MIDI regions with thousands of notes, this can represent
real overhead. This approach dispenses with the rect list,
since our Canvas drawing model only uses the union rectangle
anyway.
Code within the method was using @param start_time rather than start, which is a modified
value required to generate the correct results.
This comment also contains some logical reordering, optimization and commenting
on this rather complex method.
Note that the value is still defined in Beats (ticks) rather than seconds
which means that the interpolation density is tempo-dependent. This
should still likely change one day.
The tooltip should remain visible until the mouse leaves
the item's bounding box. Also do not start the tooltip
timeout if the item does not have a tooltip.
::start_audio_export() may be called from a background thread
which does not yet have a thread-local TempoMap.
Track::seek() calls ARDOUR::AudioPlaylist::read()
which calls Playlist::regions_touched_locked() which may require
a TempoMap to calculate overage with Temporal::Beats
This fixes mp3 export on Linux/ARM (Raspberry Pi) with
system-wide dynamically linked ffmpeg. Otherwise the there
would be library conflicts with ardour-bundled libz and libcairo.
This allows regions to be correctly imported to their
actual track number now that they are numbered from zero
without any gaps by ptformat, removing the need for a lookup table.
In layered mode the scroomer is not usable with stacked MIDI regions.
Ideally we'd only hide it if there is more than one layer
but that is for another day.
Pane::set_divider() constrains the divider so that widget
minimum sizes are honored.
Initially the mixer is empty and the tab has width of ~110px
(just scroll window). Pane::on_size_allocate() calls set_divider()
before actual mixer-strips are added and before the mixer window
size was restored. This incorrectly constrained pane sizes.
This was broken during development of ripple-all.
First explicit rdiff_and_add_command() was used, but
when that was reverted later, the original stateful_diff
was not restored.
989408626d1ccf272d58
std::upper_bound() was not the correct tool to find the existing point,
it should have been std::lower_bound(). For code consistency, this
change doesn't use either but like ::remove_tempo() and similar methods,
just iterates over the whole list
