I’ve been somewhat frustrated with the occasional +5V freeze at start with Resonator/Annuli. It occurred to me that the sporadic nature suggests an uninitialized instance variable, and so I went digging through the Rings/Resonator class in the eurorack repo, and I found that previous_position_ never gets assigned an initial value. Is the value used prior to it being sane? As an experiment, I set it the same as position_ in Resonator::Init(), and so far, the Mutable Instruments Resonator (I don’t use Annuli typically) seems not to be starting up hung anymore. Any thought on this? Nailing this once and for all would make a very useful module a bit less problematic to work with. This idea is just a stab in the dark, and it may be completely bogus. Git blame puts the Init stanza’s last modification back in Feb 2016. (Commit: 46acd575)
Yeah, this has been an irritation/bug with Resonator/Rings from the start. Good find! There should be a bug report about it on the Audible Instruments repository, I’m sure.
Yeah there are several.
Reading the stmlib code (eurorack dependency), I find that indeed that uninitialized instance variable is indeed read before it is assigned. The lines in question are the second line of eurorack/rings/dsp/resonator.cc Resonator::Process(…) and eurorack/stmlib/dsp/parameter_interpolator.h ParameterInterpolator::Init(…). It’s pretty clear that no assignment to previous_position_ is made prior to its first reference. While I added previous_position_ = position_ after set_position(0.999f) in Resonator::Init(), it’s not clear to me that this is a correct initial value. I am not a DSP wizard. Any clues?
Anything is better than uninitialized. Without further information, I’d myself go for zero first, if that caused an issue like no sound happening, maybe then a value little bit larger than zero…If the valid range was known, I’d go for a value in the middle of the range. When experimenting with things like this, I’d also mute any outputs to speakers/headphones and look at the output signals with a scope.
So far, matching position_'s value seems to work. I can rebuild with zero initial to see if that does something pathological, but I’m expecting not. Basically it’s one end of a LERP. Sadly, Andrew’s eurorack git provides no issues menu for me to report this.
P.S. Zero as an initial value seems to work fine as well.
diff --git a/rings/dsp/resonator.cc b/rings/dsp/resonator.cc
index 63a90a4..c01f375 100644
--- a/rings/dsp/resonator.cc
+++ b/rings/dsp/resonator.cc
@@ -49,6 +49,7 @@ void Resonator::Init() {
set_brightness(0.5f);
set_damping(0.3f);
set_position(0.999f);
+ previous_position_ = 0.0f;
set_resolution(kMaxModes);
}Is there a similar bug in Elements?
Yep. I just haven’t created any patches with it, so I’ve not been bitten by it. Thanks for pointing that at me. Outside of Southpole and Audible Instruments, are there any other modules that depend on the eurorack repo of which I should be aware?
I sent a pull request to the upstream pichenettes/eurorack. We’ll see what the commentary is. At worst, I’ll learn something. Whether or not Vortico considers it worthy is another thing altogether. There, at worst, I have to maintain it out of tree on my installations.
P.S. Upstream took the P.R.
It might be worth it to start checking the other Mutable/Audible codes too for these kinds of issues. It could be that the Mutable Instruments developer has not noticed these because of the compilers/architectures involved. (Maybe for example the embedded chips or their firmware in the Mutable hardwares zero out all their memory when the device is turned on…?)
I think there is a similar one in Plaits, and I’d be curious to see if anyone else is getting this behavior. Steps to reproduce:
- drop a fresh Plaits in the patch.
- connect the OUT and AUX outputs to VCV Scope. We should see that AUX has no signal
- wiggle the harmonics knob and then double click to initialize it back to its center position, we then see that the AUX output is working, yet the module’s controls are in the exact same state as in step 1
I wonder if that’s actually expected behavior because of the oscillator sync when the oscillators start at the exact same pitch…? (I guess it could be fixed by changing the initial oscillator phase.) Maybe in hardware it’s not possible to get the Harmonics parameter at exactly zero?
I think you’re right on that, by slightly detunig the harmonics, and then initializing the knob again at eactly the right time, I was able to get the AUX output to be practically 0 again, so that seems quite logical! Nice 
The behavior is somewhat annoying, I’ve bumped into it a few times myself. So some kind of fix would be nice to have…Perhaps randomizing the oscillator phase when the module is inited would work OK. (So this is kind of opposite what this thread was originally about, I guess… 
)
I was expecting to find a similar bug in the Plaits modal resonator mode code, but so far haven’t found anything relevant. There doesn’t appear to be a “previous position” variable in any of the classes involved, but maybe I just didn’t spot it yet…
Interesting thing with Plaits: if you send a trigger pulse to the harmonics jack, it also clears the issue. This wart seems only present in the first of the “green” presets. Here, AUX is supposed to be hard synced pulses, and just maybe, there is a phase related pathology here. It’s as though the wave gets synced before it even gets to start. No ideas yet. I’ve not read any of that code. Hmmm… I’m reading the Init in “variable_shape_oscillator.h” and there’s a master and slave phase parameter. Maybe giving one of those a nudge during init, might ungum the initial AUX. Again, I’m grasping at straws, and I may be completely wrong here.
I checked that the issue in Plaits can be fixed by initializing the phase of the aux oscillator to something different than 0.0.
--- a/eurorack/plaits/dsp/engine/virtual_analog_engine.cc
+++ b/eurorack/plaits/dsp/engine/virtual_analog_engine.cc
@@ -39,7 +39,7 @@ using namespace stmlib;
void VirtualAnalogEngine::Init(BufferAllocator* allocator) {
primary_.Init();
- auxiliary_.Init();
+ auxiliary_.Init(0.1f); // prevent initial silence when Plaits harmonics parameter at exactly zero
sync_.Init();
variable_saw_.Init();
diff --git a/eurorack/plaits/dsp/oscillator/variable_shape_oscillator.h b/eurorack/plaits/dsp/oscillat$
index 47d250a..272bc3a 100644
--- a/eurorack/plaits/dsp/oscillator/variable_shape_oscillator.h
+++ b/eurorack/plaits/dsp/oscillator/variable_shape_oscillator.h
@@ -44,8 +44,8 @@ class VariableShapeOscillator {
VariableShapeOscillator() { }
~VariableShapeOscillator() { }
- void Init() {
- master_phase_ = 0.0f;
+ void Init(float initphase=0.0f) {
+ master_phase_ = initphase;
slave_phase_ = 0.0f;
I expected as much. I’m going to give a try to shoving down into the Init, and nudging the slave phase instead. I suspect the result will be the same. I suspect the actual needed delta to be very small.
Nope, I was stupid. You do need to handle it at the call site. initval of 0.25 outputs a square at the 2nd harmonic. Do you want to report this upstream?
I think the interesting thing about the Plaits bug is that it is highly unlikely to arise in the world of hardware modules for the simple reason that in software, you have an exact and perfectly stable emulated harmonics setting. In the real world, that potentiometer will show thermal noise, and the setting is unlikely to be exactly centered. 侘寂 The imperfection is the perfection. 
Is this bug fixed ? Because I still got some silent patches …