the BBT times of the newly inserted points during paste() are meaningless until
we recompute them using ::reset_starting_at(). So don't try to compute some
sort of likely value, just use the value from the cut buffer, and call
reset_starting_at() after every point inserted.
A meter (time signature) is required to do the math correctly for any operation that may
cross or reach the next bar boundary, which round_to_*() and round_up_to_*() may do.
This is used to for all selection: route, plugins,
time and region and slot selection.
Only re-pack it with different expand option when
the pianoroll is also visible
Previosuly, all meta data was thrown away. Now we retain it, so that MIDI
regions can ask about their source file's tempo & meter.
Significant engineering rework of how this all works, relying on
recently introduced API and API changes in SMF, SMFSource etc.
Because we want a default argument of false, this involved the usual
inline-non-virtual-method-calls-virtual-with-no-default trick.
Also, do NOT append data to a MidiModel or change the length of an SMFSource
unless we know for sure that added that data to the SMF object.
This changes the assumption that an SMF object only refers to
a single track when being written.
::end_track() is used within begin::write()/end_write() pairs to mark the start
of a new SMF track.
see also 6672db97. in theory re-assigning a sigc::connection
should disconnect the previous connection, but for yet
unknown reasons this does no happen here.
Changes are detected in Pianoroll::canvas_allocate(), which is a proxy for window
geometry. Since Pianoroll doesn't own a window, this is not necessarily ideal, but it
works.
* directly show at correct position
* honor multi-monitor boundaries
* hide on focus-out (e.g. switch desktops with visible
tooltip left it visible)
* remove unused `set_center_alignment` API
By default Windows has limit of 32 MMCSS threads.
Ardour uses MMCSS scheduling for for hardware I/O (audio and MIDI)
as well as for realtime process threads, and a user on a
recent machine may run into this limit.
By default Windows limits the number of MMCSS threads to 32.
This can cause problems on modern systems with >= 32 cores,
when Ardour uses many process and I/O threads.
So far this is just a first step (query API)
now that we use action-as-state, there was no way to look up the old
mouse mode when changing into or out of internal editing. this
prevented us from queuing the redisplay of trackviews that allows the track
headers to expand when appropriate.
