| Age | Commit message (Collapse) | Author |
|---|
|
Newly constructed sessions don't save "Tempo-start" property.
If there's no "start" node, _legacy_bbt is never explicitly set and
the default c'tor is used, which sets bar = 1.
The test for legacy session checks bar != 0.
All new sessions were processed with fix_legacy_session(), which breaks
the tempo-map and makes the session not loadable (duplicate Tempo).
|
|
|
|
|
|
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
|
|
|
|
This fixes various Lua-scripts: There are no explicit bindings to
turn int64_t, uint64_t into a const reference.
Besides it doesn't make sense to use a reference for constant _t that can
be directly loaded in CPU register or on the stack.
|
|
Ensure we set the last tempo end note types per minute.
Clarify that we only set the end ntpm if unset.
|
|
This could result in legacy sessions not being identified correctly and
loading with end tempi of -1.0.
|
|
Setting a tempo to 'Continue' via right click puts it in a permanent state
of continuing the previous section's end tempo (basically what
'Lock Continue' should have been). This can be disabled (unlocked) by
selecting 'Don't Continue'.
Remove the previous temporary 'Continue' function.
Reorganise menu to separate position lock style from more commonly
used functions.
|
|
|
|
|
|
Resets the previous tempo section's end ntpm to match the start
of a new section whenever a section is added to the map.
|
|
BBT time should be enough to determine the beat.
|
|
|
|
|
|
All float <=> string conversions are done for PBD::string_to/to_string and no
longer require a LocaleGuard.
|
|
|
|
TempoMap::get_grid() supplies a list of beat positions, leaving the lines
to work out any subdivision positions.
This is fine, unless a tempo section falls in between beats.
Use a BeatsFramesConverter along with a quarter note position
(in the BBTPointsList) to make this easier.
|
|
|
|
Should fix 7390.
|
|
|
|
|
|
I suspect this happened after an api change.
Now, just use the position pair instead of a whole new variable.
|
|
|
|
There are various issues with copy-construction: no readlock is taken,
Tempo/Metric Sections were static-cast to non-const pointers and passed
as references...
This remove the [now] unused copy-c'tor, and fixes various const issues.
|
|
|
|
- a tempo marker may now be set to always continue (clamped)
this means that the end tempo of the previous section will
track the start tempo during tempo ops.
it mimics the behaviour in 5.8, with the gui indicating
the curves to be changed.
|
|
- this is the opposite of 'Ramp to Next'.
it removes discontinuities between the
last end tempo and the current by altering the current one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- this implements in the intention behind the previous commit.
a tempo mark is constant until its end has been changed by a
shift-drag on the next marker.
|
|
- stretch drag (using shift on the curve) operates on
the true meaning of constant. in other words,
the only way you can make a tempo ramped is by adjusting the end
tempo (shift drag on the *next* mark). from this point onwards.
shift-drag the curve will change the start tempo and ctrl-drag
the curve will change the end (needs work). to reset the
curve to constant, 'make constant' should simply set the end
tempo (unimplemented).
|
|
|
|
most changes are due to a new design where tempo discontinuities at the
beginning of a ramped section may be set.
this allows easier mapping of live performance, especially in
the common case of a ramped ritard before the beginning of a new section.
feature summary:
holding constraint modifier (shift) while dragging the BBT ruler area
drags the tempo lines by changing the start tempo (as before)
holding copy modifier (control) while dragging the BBT ruler area
drags the tempo lines by changing the end tempo (ahem. not quite there)
dragging a tempo mark while holding constraint (shift) will change the
previous end tempo to match the marker position *worth trying*.
holding constraint and copy modifier (control + shift) while dragging
the BBT ruler area attempts to'pinch' or twist the surrounding tempi
sp that later ones are not repositioned (currently suffereng from
rounding errors)
|
|
|
|
- behaviour should match that of 4.x (move the first tempo
to frame 0).
|
|
- should fix 7234
|
|
- the initial tempo must always be locked to meter,
so i think it is safe to explicitly set it anyway.
|
|
|
|
|
|
|
|
snap now fills in a struct (MusicFrame) which contins a snapped frame
along with a music divisor.
this gives useful information wrt magnetic snap which may or may not
have rounded to an exact musical position.
region position may now be set musically (using quarter notes for now).
this patch fixes several problems in the current code:
- dragging a list of music-locked regions now maintains correct
musical offsets within the list.
- splitting regions using magnetic snap works correctly (#7192)
- cut drag should now work correctly with magnetic snap.
- musical length of split midi regions is no longer frame based.
|
|
|
|
|
|
|
|
- the beginning of what hopefully will be a saner 'pulse' definition
|
