I added an issue in the Fundamental Github repo.
4 Likes
apparently, according to changelog it: *Fix probabilistic crash when loading wavetable files.
1 Like
I hear those clicks very clearly as well on my Mac, with latest Fundamental update to v2.0.2, and it definately was not there when I first tried it on Fundamental v2.0.0. As all the clever detectives have surmised above, seems Andrew fumbled the ball with the latest update:
2.0.2 (2021-12-26)
* Wavetable VCO and LFO
* Fix probabilistic crash when loading wavetable files.
I think the definitive diagnosis is best summarized in @Xenakios 's well written issue in the fundamental github.
After reading it, I ran this test: when looking at the WT output of a sine wave using the Bog spectrum analyser with Rack running at 60 fps, I get the noticeable noise in the graph, but at 10fps it’s much much lower, so it does seem like the mutex lock in the drawing code is causing some missed samples in the audio code.
I think the idea of the mutex is to ensure a consistent look into the wavetable in case it gets asynchronously changed. My guess is that dropping samples in the audio thread is not supposed to happen normally when WT is running; now if the GUI thread loads another wavetable, since the wavetable is being updated, it’s oubviously not a problem to drop samples during the changeover, since things are changing anyways 
I guess the challenge then becomes how to make the drawing and the audio code both consult the wavetable in a consistent manner without dropping any samples.
When I was coding ShapeMaster, I had to be extremely aware of these kinds of things, and I decided to use a std::atomic_flag and manage things a bit differently. I do have sample dropping (skipping is actually a better term), but I think it’s only when the shape changes (and it’s an envelope generator also, which is more forgiving!). This is why this issue interests me a lot, multi-threaded coding is a pain but is quite fascinating!
3 Likes
I was thinking “how can this be? How can changing a control not also cause the the audio thread to run pump audio the entire time it is re-calculating the wave table”? (since parameters and inputs are processed on the audio thread, of course).
Well, it looks like those re-calc functions are only called when the json it loaded, which I think is at patch load time. I think (but am not sure) that is you change these controls after loading a module that nothing is re-calculated.
If so, that would explain the bug I logged a month ago: WT VCO does something horrible if you change wave points after loading · Issue #133 · VCVRack/Fundamental · GitHub
Looks like a fix for this is coming, there is a new commit in the Fundamental source code by Andrew.
2 Likes
2.0.3 (2021-12-31)
- Wavetable VCO and LFO
- Make wavetable loading lock-free, fixing hiccups and increasing performance.
3 Likes
Yup, no more clicking in Fundamental 2.0.3, yay!
yeah, that bug can be closed. maybe this one next? WT VCO does something horrible if you change wave points after loading · Issue #133 · VCVRack/Fundamental · GitHub