The design ignored the ratio computed by the drag interaction, and relied on getting the stretch
ratio from the dialog. This truncated the actual ratio, leading to (relatively) small errors
in the length of the generated region.
Now, if the ratio provided by the drag is not (1/1) (i.e. a single click while in timefx mode)
then the percentage stretch spinner is marked insensitive and the stretch ratio is taken from
the given ratio. For single clicks, the user can still adjust the percentage as they wish
Previously it was possible to cause a 64bit signed to 32bit
unsigned overflow. `from_stretcher` is pframes_t aka. uint32_t.
With int64_t arguments a std::min() expression producing negative
result will result in large 32bit values:
(pframes_t) std::min<int64_t>(1024, 176400 - 187392) = 4294956304
This produced a segfault when used as n_samples to copy in
buf.accumulate_from()
Because a bartime point IS-A tempo point and IS-A meter point, we cannot just delete the tempo
point passed into core_add_tempo() if the new point replaces an existing one. Ditto for meter.
So, leave that logic up to the caller
timecnt_t and timepos_t constructors with the initial argument as an int64_t
are assumed to be using samples. We need to use the explicit factory methods
instead.
Session handles the case when the button is used to enable cue triggering, by
forcing a locate to the current transport position.
TriggerBox now connects to the correct configuration object to notice when cue
triggering is disabled, and sets _cancel_locate_armed appropriately.
No behavior should be changed by this modification; the argument has a default value of false, which
matches previous semantics, and every instance where the argument is specified, it is given as false.
Disable the "More" button when search parameters change. The button is
supposed to continue the current search, but if any of the search
parameters (tags, sort, or licence) have changed, that doesn't really
make sense. Just disable it if the user changes any of them.
Make sure that filenames in the freesound results list are escaped
properly for the tooltip, and append the full licence URL returned to the
tooltip too.
Make the filename column Gtk::TREE_VIEW_COLUMN_FIXED, so that it doesn't
expand to the width of the longest filename in the results and push the
columns to the right out of view. Resizing the import dialogue larger
still allows longer file names to be seen, and it's still possible to
manually resize the filename column as well.
Only show the hours & minutes in the duration column if they're non-zero,
and justify them right.
Add a drop-down list to the freesound import tab, to optionally restrict
search results to "CC-BY", "CC-BY-NC", or "PD" only licensed sound
files. Defaults to "Any", which will return sounds with any licence.
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.
