Stem-export defaults to use selected tracks. This retains
the selection, so focus remains. Repeat stem export will use
previously exported tracks if the selection is empty, or the
current selection (again).
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.
Ben Loftis
Robin Gareus
Paul Davis
itmuckel