> warning: 'sscanf' may overflow; destination buffer in argument 6
> has size 32, but the corresponding specifier may require size 33
> [-Wfortify-source]
This replaces vector<char>::operator[] (which now
a constexpr since C++20). We could use &vector::data(),
but a unique_ptr seems more appropriate for the case at hand.
Gestures may prevent a 2nd touch from being registered as
such (and instead report a zoom/pinch gesture).
At least that is my best guess, why Nathan needs 3 fingers
to move 2 Faders :)
When we "sync-to-source" from a MidiModel (IS-A Evoral::Sequence),
we will mark the end (length) just like when capturing MIDI. So
the MidiModel/Sequence needs to know the actual length, not just
the time of the last event.
every write pass deletes existing tracks, which means it also deletes any existing
EOT event. Rather than try to replicate the _length value() that is kept in a
Source object in the SMF object, add a virtual method to SMF that returns
the _length value (or std::numeric_limits<Beats>::max() if not set).
If the _length value is not the max, we will add EOT events to each track
(usually just one) right before writing to disk.
The initial value is taken from the Config object. Currently this
is only used for stop-on-grid, and only BBT(_Offset) is observed, and
implicitly means "1 bar" for now.
MidiCueView needs an _active_notes array setup when it is assigned a track that is
already rec-enabled, because we can start clip recording without session record-enable
being active.
MidiRegionView does not need this; it uses session rec-enable status to create or delete
_active_notes (also transport stop, sometimes)
