tg
tg copied to clipboard
vacaboja
Audio Settings Dialog: take II
This PR replaces my previous PR #19 which can be ignored and closed.
1)audio interface and audio input selection. Light subsampling removed. Under the command menu, the audio setting dialog allows user choice of audio interface and audio input. Default values work best. I'm not sure these should be exposed on release builds as some combinations do not produce a signal. For Windows though, using https://www.vb-audio.com/Cable/ is the easiest way to playback recordings, so it's needed for dev builds. Sample rate can be selected too, but is not guaranteed to be available, again default values work best.
The subsampling of Light algorithm has been removed, as that can now be selected independently above. Light algorithm is now just the lowered buffer sizes without noise reduction.
2)removed round() methods from inner loops to outer loops in compute_phase and compute_waveform. These were using 5% according to vtune. No change in output.
3)SIMD alignment of all fftw buffers. There may be a reason for it, but some fftwf buffers were using malloc rather than the DWORD alingned memory that allows SIMD operations. http://www.fftw.org/doc/SIMD-alignment-and-fftw_005fmalloc.html#SIMD-alignment-and-fftw_005fmalloc Can't say I noticed any huge gains though.
4)cyan / magenta colored events a waveforms for tic / toc
Rather than all the events colored white, the tics and tocs are now colored cyan and magenta, as are the waveforms and period background. This makes it much easier to reduce beat errors as the colors switch places on the papertrace if you go too far. Off-centric escape wheels cycles are more evident too.
To maintain backward compatibility, this was done via tocs having negative eventtimes.
Methods
int absEventTime(int eventTime); int event_is_TIC_or_TOC(int eventTime);
are used to convert timings back to regular time, and to tell if a time is a tic or toc.
5)Changed Lift Angle spinner to allow floating points. 0.5 increments. Trivial change, but occasionally some lift angles are not integers.
6)Low and High Pass ranges added to Audio Settings Dialog Added range controls to audio settings dialog so user can play with filter cutoffs. These values are saved between sessions. The order and effect of the filters has not been altered.
in algo.c the numeric shift needs to be reduced to 15, or there is an integer rollover in calibration mode. Sorry about that. #define PERIOD_SHIFT 15
Added Mag+ and Mag- buttons to the controls beneath papertrace. These allow zooming in and out of events.
I've grown tired of repeatedly labeling snapshots for testing in positions. Now it's a click away.
My bad, I'd left a few #defs in that I need to build in eclipse IDE. Now removed.
I've addressed most of the issues itemized above that relate to the features: removed round() methods from inner loops to outer loops in compute_phase and compute_waveform. SIMD alignment of all fftw buffers. cyan / magenta colored events a waveforms for tic / toc Changed Lift Angle spinner to allow floating points. 0.5 increments Predefined Snapshot button names
Features audio interface and audio input selection. Light subsampling removed. Low and High Pass ranges added to Audio Settings Dialog Zoom on papertrace
have been implemented by others elsewhere, and can be ignored from this PR
Update (poorly labelled) algo.c address a problem I've seen many times whereby the accuracy of the amplitude detection has a direct effect on the reported beat error. For example in this instance the amplitude of the cyan tick has been miscalculated as around 280 degrees, whereas, from inspecting the waveform visually it should be around 250, (similar to the magenta waveform).
.
This produces a beat error of 1.1ms ( which coincides with differences between the lower scale timings of the cyan and magenta first pulses).
The problem subsides when the first pulse is too faint to detect, as then the beat error is detected directly from the third pulse, but then jumps to a different value when the amplitude is briefly detected.
Here I have simply omitted any use of first pulse measurements being used for beat errors - it always uses the third pulse.
The timing of the third (lock) pulse is generally more accurate and more reliable than the first (unlock) pulse, and I think this will give more robust beat error readings to less experienced uses. So which is theoretically correct - first or third pulse? Witschy claim the first, while I am claiming the third will be more robust, but it's actually the second pulse (the sound of the escape wheel imparting the power through the face of the palette jewel and onto the balance's impulse jewel AS IT PASSES THE MIDPOINT OF THE CYCLE), that would best dictate correct beat timings. Unfortunately, that second sound is generally not precise, but I'd suggest that both first and third pulses have equal divergence from this optimal timing, so we'd be better off using the one that is stronger and better defined.
The audio I used for these images (recorded with pre-amplified contact mic) is available at [https://horologyobsession.com/downloads/timegrapher/audiosamples/44100_21600_53degrees.wav]
update signed beat error. Beat error is traditionally measured in (positive) millisecs, ignoring the contrasting cases when the tic->toc is longer than toc->tic or the reverse. This makes eliminating the beat error unnecessarily tricky as it approaches zero as an overshoot will register the same as an undershoot. By displaying the sign of the beat error the reading will remain coherent as long as the software does not lose track of the ticking. With the caveat that the software does not actually know which is tick and which is tock, and thus might initialize reversed, the same technique used to reduce the rate error can also be used for beat error - ie the "+" or "-" (or "f" and "s" on swiss watches) indicating the direction to manipulate the stud carrier.