Exponential approach to zero:
1 / exp(t) == exp (-t)
we "stretch" it by a time-constant "c":
gain(t) = exp (-t * c)
To find the time t, at which the exponential approach reaches gain "g":
exp (-c * t) = g
take the log of both sides: log (exp (-c * t) = log (g)
since log (exp (x)) == x : -c t = log (g)
divide by -c : t = -log (g) / c
set g = 1e-5 and c = _a/sr and we get: t = -log (1e-5) / (_a/sr)
The iterative approach using g += c * (target_gain - g);
converges faster than the exact exp() calculation.
Except with 32-bit float, if target-gain is 1.0f and "c" is small.
With 32bit float (1.0 - 1e-5) = .9999900 is represented as
sign: +1 | mantissa: 0x7fff58 | exponent: 126
there are only 126 "steps" to 1.0. Rounding of the lowest
mantissa bit does matter. We have to assume worst-case,
and increase the required loop_fade_length buffersize.
vs. approaching 0, where there are over 2^110 steps between
zero and 1e-5.
If use_transport_fades() is false, then the declick_amp will have its gain always set to the current target (no declick).
Therefore only testing if it has reached zero is not enough, we need to check if we are declicking at all.
If there's no GUI property for the MIDNAM model name, and the plugin has no MIDNAM, there's no reason to set the property to the default
It will pick up the default ("Generic") during update_patch_selector() calling into model_changed
Attempt to re-use GUI property for MIDNAM device mode, and if it doesn't exist, use the first from the model's device mode list.
Also require at least one device mode in the MIDNAM file (via assert) - consider anything else to be malformed
We do not store the MIDNAM model as a GUIObject property if the using the plugin-provided MIDNAM. Selecting a different MIDNAM for
the plugin should now result in that choice being saved/restored correctly.
This all feels crazily complicated, but I don't want to change more of the architecture at this time
This fixes an issue where the size of the window stayed much larger
than its content if there are no sessions in the session search path
after attempting to make a new session and then pressing "back"
With 4MB RAM and 1.5MB locked base memory (C++ bindings),
TLSF has a better worst-case performance (-20% std-dev
execution time compared to realloc-pool).
Even though on average Realloc-Pool performs better (-9%
average time, compared to TLSF).
Since Lua function arguments are not typed, there is no
explicit "const", and a function can always modify the parameter.
When passing `ChanMapping const&` as argument, the object is
copy constructed. In this specific case the std::map<> members
of ChanMapping allocate memory.
Passing a pointer to the object works around this issue.
LuaBridge later dereferences the object as needed when calling
c++ methods, and copy-construction would only happen later.
