The peak meter needs to withstand various test-signals
without visual jitter (in particular 1kHz sine) regardless
of settings (period-size, sample-rate, custom fall-off).
This needs to be done in sync (and not by a random non-rt
‘smoothing’ thread).
On the downside this voids the ‘visual smoothing’ particularly
with large buffersizes - but then again exactly this “always
fall-off no matter what [the next real data will be]” is the
problem.
One the upside, there’s one less high-frequency (100Hz) thread
(Yay!) PS. it probably never worked on windows, anyway.
Only peak-meters are affected by his change.
K-meters, IEC I/II and VU were never visually smoothed.
ignore non-plugin processors for OSC
/ardour/routes/plugin/parameter
fixes issue with hidden internal processors. (rec-en
track adds a hidden [meter] processor at the top,
internal returns on busses have returns etc.)
Those objects do not have a versioned API by themselves.
This fixes issues with duplicate deployment (OSX, Linux bundles: cp) and
ardour listing control-surfaces multiple times (file index plugin dir).
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.
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.
