Add a new client id & token for Ardour 7, and update to Freesound's API
v2.
Implement OAuth authentication for Freesound downloads, as described at:
https://freesound.org/docs/api/authentication.html#oauth-authentication
Open the Freesound login page in the default browser, so that the user
can log in and get an authorization code, to copy-&-paste from the
browser. Exchange this authorization code for an access token, and use
it in a custom 'Authorization: Bearer $TOKEN' http header.
If logging in to Freesound to download a file fails or is cancelled,
clear the 'downloading' flag for that file in the list so that a
subsequent click on it will try to log in again.
Show login progress in download progress bar, and disable preview if
file hasn't yet been downloaded.
If a download fails for any reason (except the user cancelling it),
report an error in the Log window.
Use curl_free() for pointers returned by curl_easy_escape(), as per the
curl documentation, rather than plain free().
Also, don't use the www. sub-domain of freesound.org: although it
appears to work for most things, it returns an empty document from
https://freesound.org/apiv2/oauth2/access_token/
Remove default empty token value from Mootcher constructor, to make it
explicit when we construct a Mootcher that doesn't require
authorisation, by requiring an empty token parameter in that case.
We discovered in the past that the C++ API for GSource/Glib::Source has some fatal and unfixable flaws. Copy similar
code and just use the C API for GSource instead
The RecoderUI can show device input meters as long as a backend is
running regardless of a session. I/O Plugins are however
part of a specific session.
This is based on code from earlier commits that were later reversed, but we need some mechanism
to ensure that threads have a thread local tempo map ptr set. The big difference is that this
time we do not implement this for all instances of an AbstractUI - implementation is left to
each thread/event loop
* control points that were already closer than one_tick_in_pixels
were able to move beyond adjacent points, resulting in out-of-order lines
* prior code was using 'one tick' as the smallest spacing between two
CPs, but that is larger than the default 'guard point' spacing. this
resulted in odd behavior because of the dxt calculation when you moved
a point that was created as a 'guard point'
For now, use the same 64 samples we use for 'guard points'. And change
the 'dxt' calculation logic to more aggressively limit the points from
overlapping.
TODO: we might decide that 'one tick' should be the minimum automation
period throughout ardour. In that case we should change guard-points.
* in the case where there are no existing automation points, then
initiating an automation range drag (select range, switch to Draw)
should initialize the line at the current knob position
Stem-export defaults to use selected tracks. This retains
the selection, so focus remains. Repeat stem export will use
previously exported tracks if the selection is empty, or the
current selection (again).
Events in the delay-buffer must be shifted back every cycle.
Also in case of fixed-delay-lines events may not be in sequence
since events are only sorted at backend port-level.
citations are needed to explain when&how this is useful
the definition of Ripple is "accommodate cut/insert/moves by moving all
regions to the 'right' (later) of the operation by the same amount".
moving markers to the 'left' of the grabbed_region explicitly breaks the
definition of ripple. it makes documentation hard.
furthermore, in a more complicated session with multiple tracks, this behavior
ignores the regions on other tracks and the markers that still might be
associated with them (consider the case where you move the first region
on track A but there are many prior regions on track B with markers over
them)
