when Session emits RouteAdded, each handler (editor, mixer, trigger pages etc) will
execute their callbacks in order. But Editor::add_routes() selects the routes too,
which triggers a PresentationInfo::Change signal. This is received by e.g. the Mixer
before it has even found out about the newly added stripables. This in turn
leads to severe confusion regarding the state of the selection in the mixer,
and potentially elsewhere.
So, just add a PresentationInfo::ChangeSuspender for the scope of the RouteAdde
signal emission
Initially thew new region has a length of zero (0:0). When
merging Notes from a truncated region (no explicit note-off)
those notes are lost:
"Stuck note resolution - end time @ 0:0 is before note on: @ 0:0"
Truncate (or split) a region so that a note is cut short:
```
Region [{<--Note-------->}]
```
becomes
```
Region [{<--Note--]
^ implicit note-off at region boundary
```
When combining this region with an empty Region after gap,
```
Region [{<--Note--] [ ]
```
the result should be
```
Region [{<--Note->} ]
```
For this reason, even without a gap between the regions,
the original note length must not be restored.
The result MUST NOT be the same as the original:
```
Region [{<--Note-------->}]
```
Playlist::split can result in removal of a region
(adding two others instead). In this case the state
of the removed region (if modified) is not saved.
I/O plugin Controls are destroyed with ~IOPlug, however
Session::destroy()'s call to drop_references() still
triggers AutomationControl::session_going_away() on the
binding proxy.
This is even properly documented in session_object.h:
> A named object associated with a Session. Objects derived
> from this class are expected to be destroyed before the
> session calls drop_references().
Playlist::add_region, Playlist::add_region_internal always
adds the region to the top of the playlist, ignoring the
region's layer.
Note that there is also difference between
Region::layer and Region::layering_index.
Previously creating a new preset first attempted to load
it from disk, before creating it. This resulted in a
`XML error: failed to load external entity`.
The definitions from <stdatomic.h> conflict with <atomic>, which causes
a build failure since <atomic> is included previously.
Signed-off-by: Violet Purcell <vimproved@inventati.org>
This one is more complex than the Beats or superclock variants, because
we cannot just start from the front of the map. Instead, we have to
first iterate through the map so that we start the code in
_get_tempo_and_meter<...> from the TempoPoint and MeterPoint
in effect at the BBT_Argument's reference time.
Track::use_captured_midi_sources is called from use_captured_sources().
which is only called from DiskWriter::transport_stopped_wallclock(),
which is only called from Session::non_realtime_stop().
This solves several issues related to splitting or pasting regions, when
there is more than one layer.
Rather than assign a new group-id for "all the regions on the right of a
split", only ions that had a *prior* group-relationship should be
propagated into the new group.
Signed-off-by: Robin Gareus <robin@gareus.org>
LLVM libc++ does not have the ext/atomicity.h header. This fix is copied
from the upstream vst3_pluginterfaces repo.
Signed-off-by: Violet Purcell <vimproved@inventati.org>
The alias was only used when it was exposed in lua. It was without any
indication that it was a deprecated alias, but let's just bite the
bullet and get rid of it.
A group of functionality was only used once, in
TempoPoint::quarters_at_superclock . Keep things simple and enable
further refactoring and cleanup by inlining everything and dropping
superbeat, big_numerator and super_note_type_per_second from Tempo.
The use of big_numerator right next to superclock_ticks_per_second
seems error prone. It should perhaps just be refactored to work in
superclock domain all the time.
It seems weird that the ramped case is much simpler than the non-ramped.
This (pretty much) removes the last references to "superbeat", which
I thus doesn't have to understand ;-)
The note_type_as_beats was the only temporal thing using hardcoded value
of 1920. It seems like it just should use the usual Ardour PPQN (aka
ticks_per_beat) ... which also has the value 1920.
It is however not used after d77db816de.
There is no need for scts_set now. "Early" use of SCTS will just give the
value 0. DEBUG_EARLY_SCTS_USE can thus just check that
_superclock_ticks_per_second doesn't have the initial value of 0.
If DEBUG_EARLY_SCTS_USE somehow was set, compilation would fail because
of includes inside a namespace.
(Even without DEBUG_EARLY_SCTS_USE, any early use of superclock will
probably fail clearly with division by zero. There is thus not much need
for DEBUG_EARLY_SCTS_USE now.)
Make sure all code paths that use Temporal will initialize and reset it
properly. Some code paths (in tet runners) doesn't use Sessions, so
Temporal::reset() has to be invoked directly.
Just set the static superclock variable to 0 as initial value.
TempoMap will still be initialized early as a singleton, but we
introduce a new constructor so it is created empty (and thus not really
usable until Temporal::reset() or similar has populated it).
We can thus drop the static initialization of superclock. The default
superclock rate of 282240000 will now only live in Temporal::reset().
With this change there should no longer be any uninitialized use of
superclock_ticks_per_second(), and there should not be any problems for
DEBUG_EARLY_SCTS_USE to catch. (It is however broken in other ways -
that will be fixed next.)
The superclock rate is variable and is stored in session files since
7.0 . It is set globally when reading from a session file, and it really
should be reset to a known state whenever a new blank session is
created from an existing one. Currently, that doesn't happen. We fix
that by resetting it in Temporal::reset().
For now, we are duplicating the default superclock rate 282240000 from
superclock.h , but we can drop that when all code paths that use
superclock also use Temporal::reset().
This will provide an (extra) guarantee that
set_superclock_ticks_per_second() always is invoked before creating
TempoMap or using superclock_ticks_per_second() in other ways. The
DEBUG_EARLY_SCTS_USE in superclock.h is thus closer to passing.
Ardour uses some global variables and singletons. These global variables
can be initialized with a value prior to program execution (especially
if they are const), but some of the static variables are modified, and
it is crucial that they always are reset when switching to another
session. To keep things simple and explicit and consistent, we thus
introduce Temporal::reset() to reset TempoMap (and later on also the
superclock rate). This is somewhat similar to Temporal::init(), which
usually only is invoked once (on program start) to initialize singletons
(such as the TempoMap).
9964f20c added TempoMap initialization to Session::create() ... but only
when not using a template. This create method is mainly preparing the
filesystem for a new session, and TempoMap initialization doesn't seem
like a perfect fit for it. It also seemed odd that it only initialized
TempoMap for clean new sessions, while existing sessions and templates
initialized it elsewhere.
Instead, invoke the TempoMap initialization early in the Session
creation process. This might introduce an extra and unnecessary TempoMap
initialization when loading an existing session or using a template, but
that will be cheap and do no harm, while providing a guarantee that we
always use the same default value.
cut/copy section does copy the tempo-map, so copying
a 4 Bar MIDI section will be 4 Bars after the paste.
This does not work the other way around:
With a tempo-map, 4 bars may correspond to 10 seconds
at the source position. While 4 bars at the target
position may correspond to a different audio-time
duration. This can lead to gaps or overlaps.
Variables by these names are only used from the local wscript and when
running "waf configure", which already for other reasons only can run at
the top-level.
These variables are thus not mandatory and not used.
'top' was a constant that was set to '.', even when inside
subdirectories. It is thus not really top.
I don't know if the intent was to use the actual top (which is available
as bld.top_dir), but for now we make it explicit what we have and do.
https://waf.io/book/ says
By default, the project name and version are set to noname and 1.0. To
change them, it is necessary to provide two additional variables in
the top-level project file
- and waf code inspection confirms that waf itself only will use the top
level APPNAME.
Also, the 'waf dist' comment doesn't seem relevant - especially after
this change - and is removed too.
(Note: libs/evoral/wscript and libs/temporal/wscript still use APPNAME
for other purposes.)
https://waf.io/book/ says
By default, the project name and version are set to noname and 1.0. To
change them, it is necessary to provide two additional variables in the
top-level project file
- and waf code inspection confirms that waf itself only will use the top
level VERSION.
Some wscripts will use
bld.env['VERSION']
but that will also just use the value set in the top wscript.
Done with ad hoc scripting hacks processing unused imports found by pyflakes:
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep 'waflib.Logs.* but unused' | cut -d: -f1 | while read f; do sed -i 's/^import waflib.Logs as Logs,/import/g' $f; done
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep 'waflib.Options.* but unused' | cut -d: -f1 | while read f; do sed -i 's/import waflib.Options as Options, /import /g' $f; done
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep 'waflib.Options.* but unused' | cut -d: -f1 | while read f; do sed -i 's/^from waflib import Options,/from waflib import/g' $f; done
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep ' imported but unused$' | sed "s/^\([^:]*\):[0-9]*:[0-9]* '\(.*\)'.*/\1 \2/g" | while read f lib; do sed -i "/^import $lib$/d" $f; done
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep 'waflib.Options.* but unused' | cut -d: -f1 | while read f; do sed -i '/from waflib import Options$/d' $f; done
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep 'waflib.TaskGen.* but unused' | cut -d: -f1 | while read f; do sed -i '/from waflib import TaskGen$/d' $f; done
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep 'waflib.Task.Task.* but unused' | cut -d: -f1 | while read f; do sed -i '/^from waflib.Task import Task$/d' $f; done
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep 'waflib.Tools.winres.* but unused' | cut -d: -f1 | while read f; do sed -i '/^from waflib.Tools import winres$/d' $f; done
for f in $( find * -name wscript ); do echo; pyflakes $f; done | grep 'waflib.Utils.* but unused' | cut -d: -f1 | while read f; do sed -i '/^import waflib.Utils as Utils$/d' $f; done
As was noted in 88ee3af3ea it is unsafe/undefined behavior if two threads
sleep on the JACK request file descriptor, since there is no way to control
which one will wake and process the request. Since each thread may have
sent a different request, this can lead to a thread misinterpreting the
response because it is reading the wrong response.
This may (or may not) solve some subtle problems with JACK, but was
revealed by having a control surface (LaunchPad Pro) that registers
three ports from the butler thread at about the same as the GUI
thread is registering the auditioner. One thread read the wrong
response, and because of some slightly weird code/design, it attempts
to rename the port from within the response handler, which in JACK1
leads to deadlock (and later, zombification).
Without this, two threads can both sleep on the same communication channel, and the wake order
is non-determinate, so the wrong thread may process the response to the other thread's request.
See also 976e03c15c which does this for `route_list_to_control_list`.
Fix crashes with empty route-lists e.g. momentary solo which was
introduced in 03105aa760.
this defines how the grid interacts with other snap targets (ph, etc)
* Grid: we ignore other snap targets when the grid is enabled
* Both: we snap to both grid and other snap-targets when grid is enabled
* Other: we only snap to other snap-targets and ignore the grid, even
though the grid is enabled
Previously,
0 -> no swing (1:1, 50%)
50 -> triplet swing (2:1, 66%)
75 -> hard swing (3:1, 75%)
100 -> sextuplet swing (5:1, 83%) (default!)
150 -> absolute maximum (inf:1, 100%)
This is rather confusing...
One common interpretation uses percentages of the beat, where triplet
swing is 66%. However, that causes precision issues since it's really
66.666...
Since we already default to 100 and take "no swing" as zero, let's make
that reference point triplet swing. Then the scale becomes:
0 -> no swing (1:1)
100 -> triplet swing (2:1)
150 -> hard swing (3:1)
200 -> sextuplet swing (5:1)
300 -> absolute maximum (inf:1)
300 doesn't make any sense, so let's change the range to -250 .. 250
which covers all useful values.
Also remove the division through 100 and back, to avoid rounding issues.
Signed-off-by: Asahi Lina <lina@asahilina.net>
- Fix selection of what beats to swing (was always done)
- Fix swing strength (lack of precision rounded to 50% or 100%)
- Fix model offset not being applied properly
Signed-off-by: Asahi Lina <lina@asahilina.net>
When drawing the outline of a rectangle, the bounding
box must cover the whole pixel of the line. Otherwise
the line would be left behind when the rectangle shrinks.
The read_index is adjusted in the loop, which means that the calculation of how much
data can be delivered to the stretcher must also be inside the loop
AbstractUI IS-A BaseUI IS-A EventLoop
IS-A sigc::trackable
If we have sent a call_slot() request to an EventLoop that has not executed
when the object involved in the call_slot() functor is destroyed, we need to
ensure that the request is invalidated.
To do this, We register "notify" callbacks with the sigc::trackable that is a
base class of the object involved in the functor given to
call_slot(). sigc::trackable will call these "notify" callbacks from its
destructor.
So when the call_slot() functor's relevant object dies, and its sigc::trackable
base class is destroyed, it will invoke all of its the "notify" callbacks, which will
in turn call EventLoop::invalidate_request() and this hopefully marks all the
queued call_slot() functors as "do not call".
However, invalidate_request() requires a lock, and access to the lock is
granted via a pure virtual, EventLoop::slot_invalidation_lock(). In the
heirarchy cited above, this is implemented by AbstractUI.
When we destroy an AbstractUI, ~AbstractUI() is called first, and this destroys
the lock and changes the VTT so that ::slot_invalidation_lock() becomes a pure
virtual again.
Eventually we will call ~trackable() which in turns runs all the "notify"
callbacks, and then removes them. But when these callbacks end up in
EventLoop::invalidate_request(), we try to call ::slot_invalidation_lock() and
C++ will abort because of its (now) pure virtual status.
Therefore, we must invoke the "notify" callbacks before the
::slot_invalidation_lock() becomes pure, and that means inside ~AbstractUI, as
an explicit call to trackable::notify_callbacks().
This has not appeared before (remarkably), but became an issue when the
Launchpad Pro support code's main object (derived from MIDISurface and hence
from AbstractUI) "failed" to use sub-objects for its various methods. So when
it connects to, for example, the Session::RouteAddedOrRemoved signal, it is
connecting itself (derived from a sigc::trackable). When the Launchpad Pro
object is destroyed, it tries to invalidate all the call_slot() requests, but
this requires access to an event loop lock - owned by the Launchpad Pro event
loop, which is already destroyed!
Other surfaces have generally avoided this by using other objects to provide
methods of dealing with signals from libardour objects.
we allow use of/dependency on sigc::trackable there, so this is
both legal but also sensible.
Leave the macro definition of invalidator(x) in gtkmm2ext/gui_thread.h
because it doesn't hurt and makes some sense for it to be there. No
reason for a source module that needs invalidator(x) to load EventLoop
decl.
When we add a region to a slot, we create a new Trigger, set its region,
then arrange for an "atomic" swap with the existing Trigger. This
means that the property change signal is emitted on a Trigger that
does not yet exist inside a TriggerBox, and so cannot be found using
row/col or x,y coordinates. Pass a raw pointer instead (lifetime
management is not an issue ... or is it.
Basically, if the paste position is not zero and not on a bar line, we will a BBT marker there,
using the existing tempo & meter at that position before the paste.
If the end of the paste is not on a bar line, we will place a BBT marker there,
using the tempo & meter that existed before the paste.
TempoMap::paste() now also accepts an optional final argument that if provided is
used to name the BBT markers, if they are created
Region _length values are not stashed during tempo mapping
if the region is already in the intermediate time domain, so do
not assert when they cannot be found at the end of the operation
Enable Surface, show GUI, disable surface. repeat.
Previously this cased a crash in glibmm:
The type name `glibmm__CustomBoxed_N13ArdourSurface6NS_UF86Button2IDE'
has been registered already.
* Use dedicated port-names for UFx
* Do not show SSL-UFx device-info files in MCU
* Fix Window namespacing/missing symbols
* Address Windows ambiguous symbols (Button, Surface)
Those used to have a Mackie:: prefix, now they need
MACKIE_NAMESPACE
When re-opening the GUI, there is still a somewha mysterious warning:
```
glibmm-WARNING **: file value_custom.cc: (Glib::custom_boxed_type_register): The type name `glibmm__CustomBoxed_N13ArdourSurface6NS_UF86Button2IDE' has been registered already.
```
Previously it was possible to just press "Esc" which closes the
dialog with Gtk::RESPONSE_DELETE_EVENT and Ardour continues
to run (and may or may not crash later).
De-interlace works by first creating 16 SMF Sources, and then
only using sources that are actually required.
However SourceFactory::createWritable by default emits SourceCreated,
which added all the 16 Sources to the Session. Later adding only the
required Sources resulted in duplicate IDs.
