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 uses boost::multiprecision::int512_t when multiplying and dividing by the numerator
and denominator of a ratio_t. 128 bits would be sufficient but for some reason, the boost
docs show the 512 bit variant being very slightly faster.
This is a better solution than using a double, which although it will prevent overflow
has fairly limited resolution.
Region fades would sometimes get in a mode with weird behaviour. They
would be drawn in 2d with crossing lines, mainly moving back and forth
horizontally - not as a function of time. It would sound as it looked.
The fade would sometimes jump around when resizing. It could be worked
around by resetting the fade shape. It turned out the problem could be
reproduced by making minute long fades.
This change fixes or works around the problem.
Back story:
timepos_t (in temporal/timeline.h) uses 62 bit for integer value and the
max value is thus 4611686018427387904 ~ 5e18. timepos_t counts
superclocks, where superclock_ticks_per_second is 56448000 ~ 6e7. It can
thus store up to 8e10 seconds - thousands of years.
ratio_t (in temporal/types.h) can represent fractions as 64 bit (signed)
numerator and denominator. timepos_t avoids floating point operations,
but has operator* with ratio_t. To avoid crazy loss of precision it will
multiply the superclock count with the numerator before dividing with
the denominator.
Audio region fade in and out uses a number of increasing timepos_t
values (in a ControlList) up to the length of fade. When dragging to
resize, these values are (in_x_scale) multiplied with the ratio_t of the
new and old fade length. The problem is that the 62 bits will overflow
if using fades more than sqrt(5e18) ~ 2e9 superclock ticks ~ 38 seconds.
It will overflow into the "beat" flag and (at 58 seconds) into the sign
bit. The timepos_t values in the fade will thus jump and can be negative
or change to count beats.
To work around that problem, this changeset just use floating point
values for scaling the timepos_t values. All scaled values are stored as
integer anyway, so it should not make any actual difference for this use
case. There might however be other uses of ControlList where it matters.
As an implementation detail of this "workaround" of using double, it
could perhaps also be nice to implement timepos_t operator* (or
operator*=) for double. But I'm not sure we want floating point support
in timepos_t.
An alternative (and better) solution would be to convince the fraction
multiplication to use 128 bits. It is essential to avoid overflow -
mainly in static analysis, alternatively as runtime checks or asserts.
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.
Code within the method was using @param start_time rather than start, which is a modified
value required to generate the correct results.
This comment also contains some logical reordering, optimization and commenting
on this rather complex method.
Note that the value is still defined in Beats (ticks) rather than seconds
which means that the interpolation density is tempo-dependent. This
should still likely change one day.
Region-gain (unlike other automation) is specific to the
region and independent of the source. Region::start() offset
does not apply. When region-start is trimmed the region's
envelope is modified (not just offset). The event-list is truncated.
Any audio-region envelope does (and must) have a point exactly
at the start and end of the region.
truncate_start() can thus calculate the earliest position of
valid events with the new length relative to the last event.
The mathematical operator for that is subtraction, not distance.
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.
see also https://github.com/stump/libsmf/pull/7
* Fix validity checks of escaped data
* Handle non-EOT-terminated tracks.
* Fix buffer overflow on tempo change event
* Fix memory leaks in case loading fails
* Fix a logic errors in extract_escaped_event()
* Fix the assertion problem `is_sysex_byte(status)`
* Make libsmf more tolerant to malformed MIDI files.
(fixes import of files generated by NoteEdit)
Previously this was inherited via PBD.
On MacOS/X, this adds
"-undefined dynamic_lookup -flat_namespace"
and various "-framework .." options to linkflags
Without this flag, .dylibs fail to link usually because
of missing `-lintl` (Undefined symbols: "_libintl_dgettext")
On other systems this is a NO-OP:
CFLAGS_OSX, CXXFLAGS_OSX and LINKFLAGS_OSX
are only set on the darwin platform.
gcc can recognize various regexps in comments. Since C++17 provides
[[fallthrough]], using /* fallthrough */ consistently seems
appropriate until we switch to C++17.
see also https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
