| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Track name is implicit, so instead of "meter-<name>", showing a
translatable label "Meter" is sufficient and consistent with "Fader".
Under the hood, for introspection, the processor name remains as is.
|
|
|
|
In theory different UIs can show different meter-types, so it
can make sense to maintain the type in different places.
MeterType is a bit-set and PeakMeter implementation provides for this.
However, this is not being used, and the current implementation
was rather fragmented, cross-connected signals to keep types in sync,
allowed inconsistent meter-types in GUI and backend.
MeterType is now kept by meter itself, however it is still
saved/restored as part of the Route state.
N.B. This change breaks the API, various methods have been renamed
for consistency.
|
|
|
|
Midi meters are using linear 0..1 range, (not decibels, no log-scale
falloff).
If a track is deactivated, run() is never called. the queued reset never
executed and the meter remained at the initialization default -inf
(visually it looked like a pegged meter).
|
|
* Processor implement get_state(), classes derived from Processor
implement protected ::state() -- as documented in processor.h
* likewise for Route, Track: make ::state() a protected interface
* removal of "full_state", use explicit "template_save"
* use RAII/Unwind to skip saving automation-state
|
|
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
|
|
|
|
It is slightly questionable whether type specific methods like
velocity() belong on Event at all, these may be better off as free
functions. However the code currently uses them as methods in many
places, and it seems like a step in the right direction, since, for
example, we might some day have events that have a velocity but aren't
stored as MIDI messages (e.g. if Ardour uses an internal musical model
that is more expressive).
In any case, the former inheritance and plethora of sloppy casts is
definitely not the right thing.
|
|
* reset peak when switching type (audio/midi) or total count
* clamp to +40dBFS to prevent endless falloff for HUGE signals
|
|
Pass current (latency compensated) cycle times to plugin.
This fixes time-reporting to plugins and also fixes automation
and when bouncing (the session->transport* is not valid) etc.
|
|
|
|
|
|
|
|
|
|
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.
|
|
This works around abysmal performance (~.15ms) of
boost::function and boost::bind (in PBD::Signal).
The overall load is probably higher but the realtime
thread remains unaffected.
|
|
|
|
|
|
merge windows branch to get changes from there
|
|
|
|
|
|
get compilers to agree on the type
|
|
|
|
* forward midi-data around plugins that have no MIDI-out
* allow to insert plugins with no MIDI-input at a point with one MIDI-channel
This works because excess ports (both plugin and route) remain
unconnected and use scratch-buffers.
Tested with LV2, LXVST and LADSPA.
(AU plugins with variable in/out retain the old behavior, no bypass)
fixes http://tracker.ardour.org/view.php?id=5630
|
|
|
|
|
|
|
|
|
|
before this change:
1) switch to 'custom' meter point,
2) deactivate meter processor.
-> meters does not run regardless of meter-point
-> meter can only be re-nabled in 'custom' mode
|
|
..and continue to calculate fall-off in
audio-cycle (rather than UI thread)
TODO: check if this works properly when switching
between audio/midi meter modes on a midi-track.
One of the motivations to always reset meters when the
meter-point changes was to resolve peak-hold & fall-off
issues when a midi-meter replaces an audio-meter and vice
versa.
|
|
|
|
|
|
|
|
|
|
This reverts commit d80f672e8487f459d76ab291958bffcded08f0fd.
|
|
|
|
|
|
This reverts commit ce621d1c8a600853be0020942a9664ccee0ab165.
This reverts commit 80aa2574819e947668092c660d767e25a661c6f1.
|
|
|
|
fast_coefficient_to_dB() returns a lower bound value, unsuitable
to catch audio peaks. The difference to 20*log10 is as large as 0.4 dB!
The effective speedup of fast_log10 compared to log10f is marginal
(sweep of all 24bit values)
i686 (1.6GHz Intel core): 2.36 [times faster]
x86_64 (core2 2.4GHz): 1.63
x86_64 (I3 2.80GHz): 2.03
the execution time of one log10f() averaged over a
sweep of all 24 bit values
i686 (1.6GHz Intel core): 0.131 usec
x86_64 (core2 2.4GHz): 0.033 usec
x86_64 (I3 2.80GHz): 0.044 usec
PeakMeter::run() is called from dedicated non-rt, no harm done.
|
|
|
|
|
|
|
|
|
|
|
|
|
