The infinite loop would happen if the 2 supplied paths were on different Windows drives - for example if one was on drive C:\ and the other on drive E:\
I don't think this new test will be detrimental to the other platforms but if it is, we could easily separate it out with a '#ifdef PLATFORM_WINDOWS' directive.
This gets us around a problem when converting a session from the old (Ardour2) format - where the Session Range (start) value was getting incorrectly set if we hadn't already set the end value.
at the time the graph gets around to takes down
client threads, the jack-backend’s jack_client has been reset.
But never mind: libjack does not care about it, anyway.
Don’t statically initiate the lv2 world, use explicit call after
scanning bundles.
lilv_world_load_specifications() and lilv_world_load_plugin_classes()
are only ever called after lilv_world_load_all(), so we postpone
the call to it.
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.
