clear_events() must run in realtime context, which is likely to be asynchronous
with respect to the thread that calls it. So allow caller to pass in a functor
that will be executed (also in realtime context) after the clear is done.
Additionally, allow for a cross-thread callback to the event loop/thread which
initiated/allocated the clear event request so that it can flush its own pending
loop. This part probably isn't necessary but doesn't hurt and is a useful model.
The event would be placed back in the free list at the next event allocation
by the calling thread anyway.
Expanded API splits apart some CrossThreadPool functionality, and provides
access to current pool status information (available(), total(), used(), pending_size())
The region is the un-coalesced set of rectangles that were requested for redraw. The area
is the coalesced single rectangle. In the worst cases, the coalesced rectangle could span
the entire window even though just two pixels in opposite corners were to be redrawn.
There is a problem with the verbose cursor as it is dragged across MIDI tracks. TO BE
FIXED.
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.
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)
Search scroll groups for event delivery from top to bottom rather than bottom
to top. Overlapping scroll groups still aren't properly supported by the
canvas, but currently all we care about is that the top one gets the event, so
the hscroll group (tempo lines) can be below the hvscroll group (tracks), but
the latter gets events.
These changes are MSVC specific and shouldn't affect the other builds.
(incidentally, libpbd already offers a function called 'fast_log2()'. Not sure if that could have been used instead...)
LTC-slave: offset the parsed LTC-frame instead of changing the
frame's timestamp. This fixes an issue with freewheel timeout and
delta-calculation. Align transport-time with output to match
capture alignment: "with existing material".
LTC-generator: follow suit. align clock with master-bus out.
This is a semi-permanent workaround. Once [tracks feeding] the
master-bus is/are delayed to align to output. The generator
needs to use (worst_track_latency not worst_playback_latency)
This shows that PBD::Timer is pretty much identical in terms of timing and CPU
usage as Glib TimeoutSources.
They also show the differences on Windows when setting the minimum Multimedia Timer
resolution using timeBeginPeriod
We're still a very long way from tolerant of weird SMF files (libsmf takes a
"crash if input is not exactly perfect" philosophy, if we're going to be polite
and elevate such a thing to "philosophy"), but at least we'll get what's there
from files truncated by old broken versions of Ardour or other situations.
I can't figure out why a change has a NULL note; that shouldn't happen, but it
does. Worse case scenario is some undo loss, so better to print something
informative and soldier on than crash. Hopefully this will help track down the
real cause with more testing.
Much like everything else in midnam, it's not specified whether the numbers are
0 or 1 relative, but everything out there seems to be 0 relative and this
matches the canvas, so go with that.
Locking should prevent this from being a problem, but taking a reference to the
cached iterator and mutating it directly causes occasional crashes for me for
reasons I can't quite figure out.
This fixes the issue and is arguably more sane anyway, so whatever.
Use Variant to store the value and the same code path for all properties.
Factor out getting the value of whatever property instead of special casing the
handling.
Towards using this stuff for some fancy things...
error: call to function 'operator>>' that is neither
visible in the template definition nor found by argument-dependent lookup. 'operator>>' should be declared prior to the call site.
IOW. types.h must be included before using ‘ss >> (T) value’ in
template in pbd/configuration.h
This fixes a design error of using zero as the flag for an "Immediate" event's action frame. Zero
is a perfectly legitimate action frame for an event (e.g. a Skip event), and using zero was causing
skip events with action-frame == 0 to be treated as immediate, not scheduled.
This is a little hard-edged in that edits while rolling will prematurely chop
off any playing notes, but at least the state of things actually reflects
reality. More sophisticated solution hopefully to come...
This shouldn't be necessary: Mixbus should probably just have a different
value for the default in their source tree instead.
This (partially) reverts commit 631467f0bb2a2756c4216738ded804663b44a2a1:
I now realise that I accidentally rolled another fix (missing "region-" in
config variable name) in there too: sorry about that.
Mixbus prefers that both the newly-created regions as well as the existing
selection are selected after splitting selected regions: make this the
default on Mixbus.
Add a configuration variable to choose the behaviour of the region
selection after splitting selected regions.
Add options to choose between all eight possible combinations of 'existing
unmodified selected regions', 'newly-created regions to left of split',
and 'newly-created regions to right of split', but comment out all but the
three least crazy ones for now. If anyone wants them, they're there.
Child items will be hidden when their ancestors are hidden. The old ::visible() implementation didn't reflect this. In addition,
when changes are made to hidden items (new definition of visible/not visible), don't bother to request redraws, since this will
be done when the item becomes visible again.
Unfortunately we store the state of models as simply model, so if there's ever
duplicate model names, we're somewhat screwed, but this makes the (previously
unmanageably huge) menu usable, while retaining the "model name as global
identifier" state unmodified.
This was a very clever attempt to fix a non-problem. If the platform doesn't have enough file descriptors available
then the platform is broken and we're not going to hack around trying to fix it.
