I’m trying to port the gen~ lores filter to genexpr.
The odd thing is, sometimes it behaves like the original,
and sometimes it sounds like the filter isn’t using the
second order of feedback, I’m wondering if History
objects are ok to be chained like this in genexpr.
Code below to paste into CodeBox. inlets to gen~ should be
audio, cutoff, resonance. Its a bit messy because I was trying
to hunt down the cause of the problem, so everythings on
History ya; // y1=z^-1 History yb; // y1=z^-2 // rps = in2*2*PI/samplerate; rps = cos(rps); // res = clip(in3,0,0.99999); res = res*0.125; res = exp(res); res = res * 0.882497; rps = -2*(rps * res); res_sq = res * res; // scaled_input = in1 * (res_sq + rps + 1); output = scaled_input - ( (ya * rps) + (yb * res_sq)); out1 = output; yb = ya; ya = output;
this is a very strange thing. should be a simple issue but appears not.
for example, the following code compiles fine without errors and works when you first turn on the audio:
History ya(0), yb(0);
frad = cos(in2*2*PI/samplerate);
res = 0.882497*(exp(clip(in3, 0, 0.999999)*0.125));
scl = (frad*res)*-2;
r2 = res*res;
scin = in1*((scl+r2)+1);
oput = scin-((ya*scl)+(yb*r2));
yb = ya;
ya = oput;
out1 = oput;
…however, if you edit it or anything else in the gen~ patch it loses one of its historys and the resonance messes up somehow. it’s really annoying me now!
the general rule of history feedbacks in GenExpr seems to be declare, use, update; but this is stumping me.
i say it might be a bug of some sort and you should email into support or something.
good luck .
Hi Pyr, Pid,
Unfortunately this does appear to be a bug in parsing the data-flow of multiple chained History operators in GenExpr. This will be addressed as a matter of urgency for the next update. In the meantime, if chained history operators are needed, the visual patching environment is working well.
FYI this bug has been fixed in our development builds, and will be part of the next update.
Forums > MaxMSP