This happens in in Ardour's Preference dialog with
e.g. BufferingOptions:
~OptionEditorContainer deletes the Option, which in turn
deletes the Widget BufferingOptions:_buffering_presets_combo
Since the widget is not managed it is not removed from its
parent.
Later ~OptionEditorContainer disposes the page layout, which
eventually also calls the Frame d'tor, causing a heap-use-after-free.
This was implemented to try to fix paste() but was not needed. It might be
useful in the future, or just as an expression of the logic of this. Note that
the BBT_Offset it returns only has the beats field set, which is ... odd. So
this is likely not quite finished.
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.
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.
* 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)
Prefer a single signal and bit flags, instead of individual signals.
This allows to call resort_route() at most once (if at all for
certain changes).
Notably Mixbus comp/gate/eq type changes can use NoProcessorChange
to only request a GUI update.
'available' was being created and deleted every time setup_vpot was
called. now it is only created when making the subview or switching the
dynamics type
