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)
Having removed boost::function.hpp we need to replace it with gtkmm2ext/actions.h - otherwise, glibmm/refptr.h can't make sense of the type 'Gtk::ActionGroup' (go figure...)
Rename the worker functions to make it clear that their name in this
case isn't magic. These functions "are not" the waf commands. It is the
custom build context class definitions that define the i18n commands ...
which will invoke these top level worker functions which in turn invoke
the others recursively.
The bare printing of the build environment in the top level i18n command
seems to be old debug code that safely can be removed.
Try to make it a bit more clear what is going on with class and def for
i18n commands.
It was confusing that we first defined i18n classes in the beginning of
the wscript file, and then replaced them with "plain" functions with the
same name at the end. pyflakes also didn't like it.
It seemed magic. The i18n functionality easily broke if trying to touch
that. It deserves an explanation to make it maintainable ... and some
cleanup.
Simple functions in the top level wscript file are generally exposed as
custom waf commands. The command will have the same name as the function
and will get a plain Context. But that simple method doesn't work for
these i18n commands. They have to be declared in a different way with a
custom BuildContext, as seen and described in the comment.
The name of the BuildContext classes doesn't matter, so we change the
name to avoid the name collision and to give a hint how they actually
just are contexts for the commands - they are not the command itself. We
also place the classes next to the corresponding functions so it is more
obvious that they are related.
