Rebasing the feature branch against master was too messy, and only these two files were
changed. The development history of this branch could easily have been --squash'ed anyway,
so not much of a loss
CF reports occasional “rendering icon 1 at size 1 x 1”
always followed by “rendering icon 1 at size 21 x 21”.
Probably a GTK bug with some specific version of GTK.
Always copy MIDI files, they are small and they get rewritten for lots of reasons, which can cause confusion
if the user elected to NOT "copy media" since the file ends up existing in both the new and old (but in use)
session.
Avoid copying analysis files on Windows, where for now the files contain illegal colon characters
If given a full path that points outside the current session but is within another ardour session,
attempt to use the peakfiles present in that other session.
- Many changes to the "User Interaction" pane wrt key modifiers.
- Snap is now relative by default (override to absolute with the
"Snap to absolute using:" modifier).
- Midi notes now obey both snap modifiers (disable snap and absolute snap)
- Timefx drag now selects the primary region (less user confusion).
- Includes MIDI event id fix.
- probably fixes a lot of cases where note ids are assumed to be
unique (they weren't for copies and some others).
- wrong branch, but it needs testing.
- Also makes "Mod4" Appear as "Windows" and adds new combination
"Alt-Windows" to the dropdown.
- Attempt to set a pair of default snap modifiers (without
knowing what it actually is for OSX)
- Copy modifier now saves
- Snap modifier modifier problem still remains.
- Copy modifier still doesn't save
- Testers please edit the Extra section of ~/.ardourN/config to allow
defaults to "take"
- Note that the current defaults overlap.
- warning - absolute snap modifier has no default and will be always
"on" unless you set it!
Note that no defaults are set - go to prefs->user interaction to
ensure that nothing is set to "no modifer"
also - the copy modifier doesn't actually save its state yet.
- user can abs/rel modifier key in prefs->user interaction
suggested for linux - absolute->alt ignore snap->alt-shift
- Constrained mode works the same as button 2 drag (initial move
sets constraint axis).
Currently we don't do anything special on layering prefs change
(relayer only occurs when each playlist is first edited). The idea here is
that "undo" is still available to restore previous layering in case of any
surprises.
marginal improvement on x86_64 for zero, 5-10% for tiny numbers;
100% time improvement (half the time) on i686 with zero.
#/bin/sh
g++ -x c++ -O3 -ffast-math -o /tmp/a.out - << EOF
#include <stdio.h>
#include <stdlib.h>
#include <cmath>
#include <limits>
static inline float accurate_coefficient_to_dB (float coeff) {
#if 1 // try me
if (coeff < 1e-15) return -std::numeric_limits<float>::infinity();
#endif
return 20.0f * log10f (coeff);
}
int main (int argc, char **argv) {
long long int i;
float f = 0;
if (argc < 3) return -1;
long long int end = atoll (argv[1]);
for (i = 0; i < end; ++i) {
f += accurate_coefficient_to_dB (atof (argv[2]));
}
printf ("%f\n",f);
return 0;
}
EOF
time /tmp/a.out 100000000000 0.0
time /tmp/a.out 100000000000 0.0
time /tmp/a.out 100000000000 0.0
The peak meter needs to withstand various test-signals
without visual jitter (in particular 1kHz sine) regardless
of settings (period-size, sample-rate, custom fall-off).
This needs to be done in sync (and not by a random non-rt
‘smoothing’ thread).
On the downside this voids the ‘visual smoothing’ particularly
with large buffersizes - but then again exactly this “always
fall-off no matter what [the next real data will be]” is the
problem.
One the upside, there’s one less high-frequency (100Hz) thread
(Yay!) PS. it probably never worked on windows, anyway.
Only peak-meters are affected by his change.
K-meters, IEC I/II and VU were never visually smoothed.
The processor-box GUI only allows to move the
custom meter position between trim and main_out/panner.
Previously an initial switch from In -> custom or Out -> Custom
left the meter at a position that can otherwise not be reached
by manually repositioning the custom meter.
This works around abysmal performance (~.15ms) of
boost::function and boost::bind (in PBD::Signal).
The overall load is probably higher but the realtime
thread remains unaffected.
Due to the change to use a 64bit timeline (int64 as opposed
to previously [unsigned] pframes_t) many cases special to tape-tracks
no longer work.
e.g. region->length() can returns -1, rather than INT64_MAX.
which breaks ‘overlap’ in Evoral::Coverage. which in turn
breaks tape track’s use of ::find_next_region().
This commits begins the slow process to move away from relying
on integer overflow to wrap negative numbers for tape tracks and
restores basic functionality.
Still various edge cases pertaining tape tracks remain. particularly
when changing the session start-time and moving destructive regions.
