Events in the delay-buffer must be shifted back every cycle.
Also in case of fixed-delay-lines events may not be in sequence
since events are only sorted at backend port-level.
citations are needed to explain when&how this is useful
the definition of Ripple is "accommodate cut/insert/moves by moving all
regions to the 'right' (later) of the operation by the same amount".
moving markers to the 'left' of the grabbed_region explicitly breaks the
definition of ripple. it makes documentation hard.
furthermore, in a more complicated session with multiple tracks, this behavior
ignores the regions on other tracks and the markers that still might be
associated with them (consider the case where you move the first region
on track A but there are many prior regions on track B with markers over
them)
this solves the oft-recurring problem where we assign
a beat-count of '3' or '7' because minipm mis-detected the tempo,
and that situation is vanishingly rare. it's better to assume 4 or 8
the user always has the option to change the number of beats (and
therefore the detected tempo) manually, for those clips that are
in a different time signature. but minibpm cannot be expected
to help us there.
NOTE: this is a fallback to make things 'just work' lacking any other context.
* if the tempo is detected in the filename, we use that instead
* clips that were recorded to the timeline use that bpm+timesig
* in the future we can use file-metadata (acidized wave?) instead
* this is audio-only: midi files can have an embedded timesignature
but... given no other information, experience says the vast majority
of downloaded/purchased clips will be 1,2 or 4 bars at 4/4.
omega can be computed from Beat or superclock duration. This gives rise to
different units for omega, and we must use the correct value in a given
context.
This commit also changes the way that the audio time omega is computed during
TempoMap::reset_starting_at()
Rampable only existed to provide exclusive access to ::set_end() for the
TempoMap. More idiomatic C++ but now that _type has also gone away, so has
::set_ramped() and it really was not worth keeping it around.
Ramped/Constant is really a function of start/end note_types_per_minute. Having
a separate member is really just caching it and leads to errors or risk thereof.
MidiBuffer::read_from() clears the buffer, so events were not
accumulated into the delay-buffer.
This also includes a small optimization and comments for the
variable delayline.
* when you copy a Range into a playlist, the playlist's 'timeline' should
begin at the start of the selected Range. Regions should retain the
offset they had from the Range's start.
The state was inconsistent after using the "All" buttons, causing
confusing behaviour. Most visibly, the message "No timespan has been
selected!" message and the disabling of the "Export" button were not
cleared.
Fixed by making
ExportTimespanSelector::set_selection_state_of_all_timespans call
update_timespans and CriticalSelectionChanged , like for example
ExportTimespanSelector::update_range_name and
ExportTimespanSelectorMultiple::update_selection do.
* this fixes the Draw tool when adding notes; if you tried to draw in
a region with a trimmed front, the note would not get added in the correct
location
Robin Gareus
itmuckel
Ben Loftis
Paul Davis
Mads Kiilerich
luz paz