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.
fixes#6277
This indicates a deeper problem though. Even removing a punch-range never
clears out the events. and ession::process_with_events() does not use
process_without_events() until re-start.
This still leaves cache_aligned_malloc() in
libs/pbd/malign.cc pending _aligned_free (windows crashes when using
free() on memory allocated with _aligned_malloc()).
So far however there seems to be no issue with default malloc
for audio+midi buffers on win32…
1) Disambiguate 1.0 to GAIN_COEFF_UNITY, and 0.0 to GAIN_COEFF_ZERO
2) Add GAIN_COEFF_SMALL which replaces SMALL_SIGNAL (-140dB)
3) GAIN_COEFF_SMALL can used to avoid interpolating towards -inf on a db scale
4) GAIN_COEFF_SMALL is used to detect very small (denormal?) gains and memset to zero
The tool mp4chaps by the following command
$ mp4chaps -i test.mp4
looks for the file "test.chapters.txt" to read the chapter marks
from. So removing the original file name extension (e.g. wav or flac)
makes it slightly more convenient for the user.
Players like vlc seem to stumble, if there es no chapter at the zero
position. As Ardour wouldn't let us put a track mark at the zero
position we can just use our header_func to put some kind of dummy intro
chapter. If a future version of Ardour allows track marks at zero, we
need to do a bit more work.
The mp4 file format supports chapter marks using the so called
mp4chaps format to enable chapter wise navigation in an mp4 file. The
format is like
hh:mm:ss.sss Chapter Title
This commit adds the ability to export those kind of chapter marks
along with TOC and CUE marks. The filename extension for the chapter
mark file is "chapters.txt". The format specification description is
"MP4ch".
Copy the 'Cut time' code from Mixbus, making a few obvious fixes to work in
A3 (e.g. nframes_t => framepos_t / framecnt_t).
Seems to work to move & remove markers, tempo & meter markers, and regions on
selected tracks.
Still TODO:
- use existing A3 'Insert time' dialogue
- make it respect 'No selection = all tracks'
- rename the command to something like 'Remove time' or 'Delete time': 'Cut'
sounds to me as if the removed range should end up on the clipboard ready
to be pasted somewhere, which of course it doesn't.
[Details] This bug does not show up when buffers are 16 byte aligned, but when they are not - this bug will lead to crash.
I tested all these functions with non-aligned buffers as well as long they do handle the situation with unaligned buffers.
[To be reviewed by] Paul Davis
towards fixing #6238 and #6096.
GUI thread:
#2 Glib::Threads::Mutex::Lock::Lock
#3 Evoral::ControlList::eval
#4 Evoral::Control::get_double
#5 ARDOUR::AutomationControl::get_value
#6 ProcessorEntry::Control::control_changed
..
#15 PBD::Timer::timeout_handler
at the same time: Audio Thread (try-lock, fails)
#0 Evoral::Curve::rt_safe_get_vector
#1 ARDOUR::Amp::setup_gain_automation
#2 ARDOUR::Route::process_output_buffers
Due to the failed try-lock.. AMP::_apply_gain_automation
is false. and Amp::run() uses a different gain factor.
-> click.
Mixbus in particular uses both types of tooltip so we might as well make them look the same.
N.B. The appearance is fine now on Windows but needs to be tested on the other platforms (i.e. some tweaking might be necessary).
All canvas objects share just one tooltip object which is based around Gtk::Label. The Label expands if the current tooltip text is wider than the previous text. However, it doesn't shrink again if the next tooltip has shorter text. Eventually, this results in some very strange looking tooltips (especially in Mixbus where they're used quite extensively).
Deleting the object after use will force a new object to get generated next time (at the correct size). There's still only ever one object per canvas but it's no longer persistent.
This reverts commit 6ba555c2f5.
which does not yet take monitoring states into account.
Ideally the case handled here should not happen in the
first place, It should be fixed in session_transport
transport_sub_state.
If there's port-latency > period-size, there is a
split cycle with (this_event->action_frame - _transport_frame).
Yet Session::check_declick_out() keeps PendingDeclickOut if
StopPendingCapture is set. The route declick’ed twice:
Once with the period-size and one with the remaining frames,
which resulted in a click.
fixes various fader zipper noise issues.
It voids sample accuate fader automation (the fader-gain
is low-pass filtered at 10Hz). Yet all musical purposes this
makes a lot more sense than sample accuracy anyway.
This does NOT work with MIDI files at present, because of SNAFU in SMF class, where end_write()
opens the file on its own, without _file_path being set. Needs some careful work, because basically
the SMF<=>SMFSource relationship is not tenable
* don’t allow to rename read-only sessions
* prevent periodic save (while rename is in progress)
* no renaming while actively recording (peak files
among other things will mess things up)
