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
Files that have many tracks, each with tempo information
were near impossible to load (30+ mins on modern 4.2Ghz CPU!),
because tempo is parsed incrementally:
```
For each new track:
for each new tempo-event:
rewind()
for each loaded track so far:
for each event on this track so far
```
This reduces the complexity from O(tracks^2 * tempos^2)
to O(tracks * tempos).
"Come Thou Fount Tempo Map.mid" has 238 Tracks and 56168 total
Tempo Changes (236 per track). This now requires only 56168 iterations
in smf_create_tempo_map_and_compute_seconds, rather than 1.64e+9
iterations
Now that we use superclock_t for audio time, it is possible for the square of an audio time value to overflow int64_t quite easily.
This change fixes that (and cleans up other code a little), but probably a different solution would be a good idea
This breaks MIDI files that have events ordered On,On,Off,Off, and only fixes
the "malformed" On,On,Off. Correct fix requires collecting all events occuring
yat one time, sorting into Off,On and then merging.
This reverts commit 5c3e5f9afb.
We no longer store nascent notes when noteOn is received, but wait till noteOff arrives. We also
ignore all other noteOn events between the earliest received and the noteOff.
Potentially we may want to use the _overlap_pitch_resolution member at some point
to offer control of this behavior.
"While 'atomic' has a volatile qualifier, this is a historical
artifact and the pointer passed to it should not be volatile."
Furthermore "It is very important that all accesses to a
particular integer or pointer be performed using only this API"
(from https://developer.gnome.org/glib/2.68/glib-Atomic-Operations.html)
Hence initialization of atomic variables is changed to also use
this API, instead of directly initializing the value.
This also fixes a few cases where atomic variables were
accessed directly.
see also libs/pbd/pbd/g_atomic_compat.h
The motivation for this is to determine if a given event
originates from a user-controlled live input controller or
from playback from disk or a MIDI file.
This distinction is required for VST3 MIDI learn.
This fixes segfaults as well as corrupt listes when copy/pasting
due to invalid iterators.
::mark_dirty() must be called with WriterLock, and
::rt_safe_earliest_event_linear_unlocked() must not be called
while _events is being modified. The Sequence iterator
(only user of that function) does not ensure this. Only the
sequence read-lock is taken.
These are longer be used since Seuqnce has a "force_discrete"
boolen that needs to be taken into account in addition to
user-configurable ControlList _interpolation mode.
This significantly speeds up parsing MIDI files with complex
tempo-maps. e.g. "Black MIDI Trilogy_2.mid" has 24134 Tempo
changes. Prior to this commit parsing that file took over 5 minutes.
now it loads in under one seconds (libsmf only; libardour still
add overhead, and now needs about 30-40 seconds, previously
it took about 10 mins).
The problem was that every call to `smf_track_add_event_pulses()`
calls `seconds_from_pulses()` which calls `smf_get_tempo_by_seconds()`
which iterates over the tempo-map:
for every midi-event { for ever tempo until that midi-event {..} }
This does not scale to 3.5M events and 24k tempo-changes.
