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 631467f0bb:
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.
