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.
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
This allows two reader threads to proceed without blocking each other, as can
happen when the butler renders a MIDI track into an RT-safe buffer while the
GUI reads the same MidiModel/Source for visual display.
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.
It is an offset from an *implicit* origin (the source zero), not from an explicit origin,
and this fits with the concept underlying timepos_t. A timecnt_t requires an explicit origin,
which makes no sense in this context (just as it doesn't for the timeline as a whole).
This is the libraries-only edition. It still features liberal use of Beats::from_double() but this is now
explicit and will be easier to locate the calls and remove them. Several classes that were using
Beats::to_double() have been (temporarily) made friends of Beats to allow them to keep using it,
pending the much more widespread redesigns of several structures. Once this is done, the friend
relationships can (mostly) be removed. It is expected the ARDOUR::Variant will need to continue
as a friend because it is used to pass beat counts to LV2 as doubles
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
- add more debugging output detecting regions whose
beat and frame position do not align on a playlist.
this is required as a check as we have never used
frame rounding on constant tempi before 8884a5723dc
Fixes the multiple reader issue #6541 properly without resorting to a
linear search kludge.
All the read state has been pulled out into a MidiCursor which the
caller is required to pass. The playlist keeps cursors for all the
regions it is reading, any number of cursors are allowed at a time.
MidiCursor should probably be made a smarter and more fool-proof
object (and/or possibly merged with some of the other tracker/fixer
stuff) but for now I wanted to keep it simple.
To export a MIDI region to a file, the code used MidiRegion::clone()
since it takes care of creating a new file-backed source with the wanted
contents. Nevertheless, it had several side-effects:
- it created and registered a new region which is confusing to users
- it only exported notes that were in the region range, but didn't
remove the region start offset from MIDI events, essentially producing
a spurious silence at the beginning of the exported file (this is not
a problem for region cloning because the newly created region is made
aware of the offset and caters for it).
Add a dedicated code path for export, that uses the new offsetting
capabilities of MidiModel::write_section_to().
A somewhat hacky solution to address missing note-off events when a
linked midi-region is used on separate tracks at the same time.
see the source-code comment for further info.
This moves MIDI channel filtering into a reusable class and moves filtering to
the source, rather than modifying the buffer afterwards. This is necessary so
that the playlist trackers reflect the emitted notes (and thus are able to stop
them in situations like mute).
As a perk, this is also faster because events are just dropped on read, rather
than pushed into a buffer then later removed (which is very slow).
Really hammering on mute or solo still seems to produce stuck notes
occasionally (perhaps related to multiple-on warnings). I am not yet sure why,
but occasional beats always.
This avoids stuck notes if active notes are edited, but without stopping all
active notes in the region on any edit as before.
This implementation injects note ons in places that aren't actually note
starts. Depending on how percussive the instrument is, this may not be
desired. In the future, an option for this would be an improvement, but there
are other places where "start notes in the middle" is a reasonable option. I
think that should be handled universally if we're to do it at all, so not
considering it a part of this fix for now.