On 09.09.24 18:41, Kristian Amlie wrote:
Good point, I went for that approach instead. 🙂
This is the backtrace I got:
#0 0x000000003bbc24be in ()
#1Â 0x00007fff23c881f3 in Filter::setfreq_and_q(float, float)
(this=0x7fff800478d0, frequency=7393.34619, q_=0.740651846) at
/home/kristian/code/yoshimi/src/DSP/Filter.cpp:107
synth = @0x130}
Looks mostly fine as well, except maybe for the last value: "synth = @0x130"
looks a bit suspicious, or?
Indeed, this is what seems strange.
If this is true, then we'd have some kind of data corruption
Other than that, the call path looks completely regular.
For the fix with the EQ graph rendering, I did some tweaks to EQ and the
AnalogFilter it uses. On that occasion, I switched the Effect hierarchy
over to using SynthEngine& and made them non-copyable. This is a lot of
routine changes, so I might have made a mistake somewhere.
Otherwise, I noticed those clone()-constructors for the Filter.
This might be a possible path where we could get in an outdated
SynthEngine reference.
I'll have a closer look, if I can connect some more dots...
A possible further approach could be to try to figure out what synth-reference
this is actually, which we see in the data dump
(I mean, regarding the logic in the code).
Obviously the problem is that we're in the core computing loop, so we
can not directly work with print statements (or breakpoints); rather
we'd need to distill some kind of trigger condition on which to hook
up diagnostics.
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
