Gtk coalesces multiple exposes into a single combined rect.
If _single_exposure is disabled, we break apart the individual expose rects for the canvas rendering.
undo (n) where n > 1
redo (m) where m < n
new transaction.
Previously the redo list was left untouched.
This would lead to utter nonsense in the redo list.
AFAICT this never worked.
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 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.
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.
For things like copying from pitch bender to a CC.
Also things like fader to pan, but that seems a bit funny. The conversion
probably needs to be a bit smarter here, perhaps taking the normal into
consideration...
I attempted to preserve the "don't draw unless different" by ditching rounding for more
precise display_span, but that didn't work. An alternative solution would be
to draw on adjustment change if there's text, since then we need to redraw
regardless of slider position, but it seemed weird even just with respect to
the slider, so I opted for this, which really definitely redraws when the
adjustment changes, period.
If this proves to be a performance issue we'll have to figure that out.
Hopefully-desired behaviour is that controls created in the GUI are linear, so
clicking in stuff works like other automation, but controls that originated
from recording are set to discrete so Ardour plays back the input exactly,
instead of doing crazy things like linear interpolation of already high-rate
user input, hold pedals, and so on.
Hopefully that remains the desired behaviour, because we're basically screwed
for ever making any control discrete by default, since we only save the mode to
XML at all if it's not the default, which is currently linear.
Shoot for roughly 30 steps for all controls.
Always keep sensible step information in ParameterDescriptor and just convert
for the UI.
This is a little weird, but it's less weird than it was before, and works.
backends - once instantiated - keep a reference to the engine.
when audioengine is destroyed, the backends must be deinstantiated.
This fixes various unit-test cases.
Among other things, this means that automation controls/lists have the actual
min/max/normal/toggled of parameters, and not those inferred from the Parameter
ID, which is not correct for things like plugin parameters.
Pushing things down to the Evoral::ParmeterDescriptor may be useful in the
future to have lists do smarter things based on parameter range, but currently
I have just pushed down the above-mentioned currently used attributes.
Remove old (already #if 0'ed) implementation of Evoral::coverage() and its
comments.
Tidy up the comment enumerating all the possible ways in which two ranges
can overlap, note the Evoral::OverlapType corresponding to each one, and add
comments to the if()s in coverage corresponding to the cases in the list of
overlap types.
Remove some commented-out assert()s that actually do happen, and re-instate
one that really shouldn't.
Fix a small typo (with -> within)
The various conditionals in Evoral::RangeList::subtract() appear to have
been there to work around
(a) coverage() not always returning the correct value, &
(b) the test suite assuming that the ->to point lies outside the range
Now that these are both fixed, the implementation of subtract() becomes
quite a bit clearer. I replaced the if()s with assert()s for now, but these
shouldn't trip if coverage() is working as I expect.
Also (attempt to) clarify the comments in subtract.
Comments in various call sites of Evoral::coverage() marking things I think
are dubious (with XXX). Also straightened up the alignment of some ASCII
art in libs/ardour/diskstream.cc
Rewrite Evoral::coverage() to (hopefully) do what it's supposed to.
Return OverlapNone for invalid ranges: if either of the ranges passed to
Evoral::coverage() have negative length (i.e. start > end), return OverlapNone
- it seems reasonable to say that a negative-length range can't overlap
anything. Also return OverlapNone from the fallthrough case, though this should
never happen.
Some of the tests for Evoral::RangeList::subtract() assume that ranges
don't contain their end (->to) point. This appears inconsistent with how
they are used elsewhere.
Add some ASCII art comments to the tests to try to clarify what they're
really testing for, and amend subtractTest1, subtractTest4, & subtractTest5
to incorporate the assumption that ranges include their end points.
This is not used anywhere in Evoral and is just a wrapper around the PBD
RingBuffer anyway. Towards a (once again?) independently buildable/testable
Evoral and fewer cross-dependencies.
for one, it can mess up the value when switching to
numeric-entry. It is also rather useless and not
Fader-like (faders are not scrollbars).
Besides, "stepvalue" is way to large and causes jumps
(sometimes step-value is even negative, see
"fast lookahead limiter", "release time"
-> some other bug)
fixes crashes:
* If the Editor-Mixer shows a channel with a plugin that
has been edited in the Mixer, double-clicking the plugin
will try to bring up a 2nd instance of the plugin-UI.
* When closing Ardour both the Mixer and the Editor-Mixer try to delete the underlying plugin, resulting in a double free.
This probably isn't correct in several ways, but it works more than it did, so
I figure it's push worthy.
Still not working:
* Saving mute automation list
* Dragged control points are not snapped to model restrictions
(boolean, in this case, but general problem)
* Line goes funny if you record mute automation
(as opposed to drawing it which works)
This was necessary due to a bug/design issue between Glibmm and Glib (see https://bugzilla.gnome.org/show_bug.cgi?id=561885)
but the problem needs to be managed by the *creator* of the IOSource and that has now moved inside CrossThreadChannel.
Add a test function to test Evoral::coverage() with all possible overlap
types. The first test (line 161) that expects OverlapExternal will fail
with the current implementation of coverage().
There's possibly still a discussion to be had about what the overlap type of
ranges with negative lengths should be: there are currently places in the main
Ardour code base where coverage() is called with ranges where start > end.
Fix compile errors in libs/evoral/test/, by explicitly calling
Evoral::MusicalTime::to_double() wherever a double value is required of a
MusicalTime.
Some of the double variables should probably really be made into MusicalTime
ones instead, but I don't want to mess with this too much.
takeFiveTest still fails for me after this, but a failing test is probably
more informative in the long run than a test that won't even compile.
Reverse the parameters of Mackie::Control::stop_touch() to make them
consistent with AutomationControl::stop_touch(), and fix up the call to
AutomationControl::stop_touch() to have the parameters in the correct
order.
Unfortunately, I don't possess any devices that speak the Mackie protocol, so
though the patch seems logical and correct to me, I have no way of testing it.
If anyone has a device with touch faders that speaks Mackie, I'd be glad of any
confirmation that it at least doesn't break anything.
* ifdef unused static functions
* brackets around assignment and comparision
* no return statement in function returning non-void
* boost concept_checks.hpp unused-local-typedefs
This lets us get a more explicit handle on time conversions, and is the main
step towards using actual beat:tick time and getting away from floating point
precision problems.
Fix initial read of discrete MIDI controllers.
Fix spurious note offs when starting to play in the middle of a note.
Faster search for initial event when cached iterator is invalid.
So much for dropping the cached iterator. The iterator is responsible for
handling note offs, so that doesn't work. This design means we have some stuck
note issues at the source read level, but they should be taken care of by the
state tracker anyway.
I am not precisely sure why the cached iterator was causing this problem, it
shouldn't be invalidated, and the times make sense. It may be some lock
related issue since the iterator holds a lock on the source.
In any case, this cached iterator was just to avoid repeated linear search of
the model, but since the model has a logarithmic search, instead just scrap all
this problematic persistent state and search for the appropriate start time
every read. No need to be careful about invalidating when anything changes.
This should probably hijack the same modifier as the guard points and work the
same on all automation tracks, but I did it this way to not change behaviour of
track automation where a default is much more reasonable.
No functional changes in this one (for easier auditing), but towards having
round up/down only if necessary modes, rather than kludging around that
situation with a double round as we do currently.
Another consequence of fuzzy Sequence timing, but if the difference is less
than a tick this should handle things correctly. If the difference is more
than a tick, something's wrong, and it might be okay to just bump forward
anyway, but I can't reproduce this and it could lead to corruption so I'm
leaving that case noisy.
This cleans up a lot of false-positives in static analysis
and also helps compilers to optimize code paths in general.
(tagging the fatal stingstream operator as ‘noreturn’ is
far less trivial)
Show fancy values on generic GUI controls, automation lane controls, and automation lane verbose cursor.
Fix text display of midiNote values.
Make bigstep of midiNote parameters 12 (one octave).
Add ARDOUR::value_as_string() as a stateless one-stop-shop for value printing.
Prepare to allow BarController (with Spinbutton) to translate
internal/interface values for the SpinBox.
(The change is irrelevant for the fader/slider itself which
always use the [user-]interface value)
audioMasterWantMidi needs plugin _info, but _info is currently only
available after instantiating the plugin in LXVSTPluginInfo::load().
vstfx_instantiate() -> effOpen -> [plugin] -> vst_callback(..,opcode=6,..) -> crash
Not doing this leaves the sources in the session list and then the session fails to open on next load
because the files are not there.
Arguably we should not announce the new files until they are complete, but this is a simpler fix for now.
Serialization of Session::save_state() will already protect against most of this, but there is really no
good reason why Evoral::SMF's API should require single-threaded/explicit serialization.
The PortMidi queue just holds a pointer to the midi events.
The same Midi events are free()d during WavesMidiBuffer::clear()
which is called at cycle start for every buffer and in the dtor
of the WavesMidiBuffer.
This follows the letter sent from Waves Audio Ltd. to Paul Davis dated February 20th 2014 agreeing to release this code
under the GNU Public License, version 2, with copyright owned by Waves Audio Ltd
