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.
Regular .h files *should* be self-contained and independent of previous
includes and guarded to only include once. Make it clear which files
that *doesn't* apply for at all.
