When refilling playback buffer, try to fill it completely, or at least
using the next-lowest power-of-2 as the amount to read. When locating,
where we use do_refill_with_alloc(), only partially fill the buffer.
Work not yet finished, but possibly promising.
Don’t call ::output() [here: SilenceTrimmer::process()]
with no data to process.
If (position + N * period-size) % chunksize == 0;
frames_left == 0 before the last call to ::output().
chunker.h:60 keeps the ProcessContext<T>::EndOfInput
flag and the SilenceTrimmer will already have done ‘in_end’ processing.
Note 1: Potentially we could have the same issue with 'AutomationLine::nth()' (although the current code seems okay)
Note 2: This (specific) problem seems mostly to affect Mixbus3 when it tries to load an old (version2) session from Ardour2. Mixbus can mark certain IO ports as being 'unused'. While loading sessions, function 'ARDOUR::IO::ensure_ports_locked()' deletes any unused ports. But later, the function 'ARDOUR::IO::make_connections_2X()' was crashing while trying to connect those (now NULL) ports. This commit fixes that crash but there's some evidence that it might only have moved the problem elsewhere. The version2 sessions now open successfully - but an MSVC (Debug) build now crashes whilst closing them (the Release build however, is okay). Someone who's more familiar with the code than me should review the Mixbus3/Ardour2 loading procedure to make sure it's safe.
When the crossfade length is only 1 frame, I got strange
gain coefficients from get_vector (63 in my case).
The function wrongly returned the x axis value.
The same source file cannot safely be used in different wscripts
with concurrency (if they were in the same wscript it works
.c.1.o .c.2.o, etc).
[387/764] c: libs/fst/vstwin.c -> build/libs/fst/vstwin.c.1.o
[731/764] c: libs/fst/vstwin.c -> build/libs/fst/vstwin.c.1.o
[746/764] cxxprogram: build/libs/fst/scanner.cc.1.o build/libs/fst/vstwin.c.1.o -> build/libs/fst/ardour-vst-scanner.exe
[750/764] cxxshlib: [...] build/libs/fst/vstwin.c.1.o [...] -> build/libs/ardour/ardour-3.dll
and about one every full moon (depending on concurrency) it failed:
missing file: 'build/libs/fst/vstwin.c.1.o'
The problem this is avoiding makes absolutely no sense. Either I'm dumb, or
something is more deeply wrong with scroll group bounding boxes, or both, but I
don't care anymore. This works. Viva release mode.
Achieve this by adding a new hscroll group just for cursors.
That requires a slightly smarter window_to_canvas() to deal with overlapping
sensitive scroll groups. New rule is that scroll groups can overlap, but the
most sensitive one found from the top down will be chosen to translate
coordinates. This basically means don't overlap scroll groups with different
sensitivities.
In the presence of scroll groups, having a canvas-wide window_to_canvas()
and/or canvas_to_window() fundamentally makes no sense. At some point in the
glorious future we should kill those and use only item-relative coordinate
translation.
pass this value up so it can be used by the engine dialog.
if for some reason the engine dialog still doesn't have a buffersize selected, print an error and try 512 instead of crashing.
This is backwards compatible, quotes are only added if needed.
JACK1 < 0.123.1-30 and JACK2 < 1.9.10-25 fail with either
whitespace or quotes, so nothing is lost.
Do not skip peaks when creating peak files while recording.
Fixes missing peaks in #6127
(TODO: after double-check and sign-off, remove ‘force’
parameter from ::compute_and_write_peaks API)
