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.
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 rest from `tools/convert_boost.sh`.
* replace boost::function, boost::bind with std::function and std::bind.
This required some manual fixes, notably std::placeholders,
some static_casts<>, and boost::function::clear -> = {}.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
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.
The actual goal here is to use direct InterpolationStyle serialization
in MidiSource (identical to AutomationList). enum_2_string()
does not work for Evoral types.
As side-effect virtual base-classes have been changed to pass
Parameters as const references
Automation Controls (and controls in general) are now
only updated in realtime context. Either via automation-playback,
or via SessioEvent. This directly sets the Control:_user_value
(before emitting the Changed signal).
The GUI does not need to evaluate the control at a given point
in time, so the API call can be removed and unified.
This commit first removes all calls to "get_double" to ensure
that no special cases exist.
This note-mode had no effect on anything at all, at least as far back
as 5.12. There is a note-mode in the GUI which affects the duration of notes
added using the GUI, and that remains in place. It is not clear
if the _percussive member of Evoral::Sequence ever had any effect on
the actual MIDI event stream the Sequence could generate.
we screen midi files for some aggregate info:
used channels, used patches, and note-count
you can't do this from open() because there are cases (after importing)
when the source exists but it is not yet written to disk
