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.
Robin Gareus
Asahi Lina
Paul Davis
Ben Loftis