We now try to get to the right location within the MIDI data and continue
playing, rather than pretending that we reached the end.
This also fixes a thinko that caused only the first few notes of a
MIDI trigger to play.
This may also solve cases where due to length, sample rate and tempo
settings, a trigger finished precisely on a ::run() call boundary.
* allow to update IR data
* allow to use mono processing in base-class
This is handy for FIR (Readable/ROM), and operating directly
on local data (ratherer than mapped buffers)
Usually C++ class instance has the same mem address as its first parent.
LuaBridge uses this to for derived classes. A TemopPoint instance has
the same address as its parent Tempo. However due to virtual inheritance
this was not the case due to a lack of virtual d'tor.
Now the following Lua code works correctly
```
tm = Temporal.TempoMap.read()
tp = Temporal.timepos_t (0)
print (tm:tempo_at(tp):note_type())
```
Previously the last line failed calling Tempo::note_type()
on a TempoPoint instance, due to memory offset e.g.
TempoPoint: 0x600000ff90e0 Tempo: 0x600000ff90e8
For some reason applying the property change
plist.add (Properties::start, std::numeric_limits<timepos_t>::min());
does not correctly reset the offset of the newly created region.
The during trim-front, the call order is
1. Region::set_position_internal
2. Region::set_length_internal
::set_position_internal sets `_last_length.set_position (position());`
but the later call ::set_length_internal does `_last_length = _length;`
This sets last_position() == position(), and later Region::mid_thaw()
does not call Region::recompute_at_start().
Region gain envelope was not updated.
see also 00a1b7cb24 and 13d10582f0
This partially reverts eced764480. In many places Ardour uses
SMF directly, without loading the MIDI model in a libardour SMFSource.
In this case no information (track, channel-count) was available,
after eced764480, and worse various members were not initialized
and showed random numbers.
This fixes various import options.
Previously, the copied source file only contained data within the initial region bounds. This
meant that you could not trim the (unlinked) copy to beyond its initial bounds. Seems wrong.
It seems that using ::move_to() followed by Pango::Layout::show_in_cairo_context() leaves
the context in a state that is not correctly restored when using ::restore(). Therefore,
clear the path to avoid leaving any dangling current point
Found via `codespell -q 3 -S *.po,./.git,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch -L acount,ba,buss,busses,discreet,doubleclick,hsi,ontop,retrn,ro,scrollin,seh,siz,sord,sur,te,trough,ue`
VST preset restore has to happen in the GUI thread, specifically
the plugin's own UI event-loop (which on Linux and Windows is
not usually Ardour's Thread 1). However if there is no plugin
GUI, it should be safe to use Ardour's UI thread.
A widget's style (font) is only set after the widget has been
packed and inherits relevant information from the top-level window.
`set_size_request_to_display_given_text()` produces incorrect
results when it is called for widgets without a top-level
(here ARDOUR_UI::setup_windows() _main_window.add(), changes the
font from "Sans 11" to "Sans 9" for ArdourDropdowns).
`set_size_request_to_display_given_text()` must subscribe to
`signal_style_changed()`, however in case of ArdourButton UI-scaling
of elements also needs to be taken into account. It is preferable
to allow for multiple sizing-texts directly.
