genexpr oddity

Nov 29, 2011 at 7:20pm

genexpr oddity


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
separate lines.


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;
Dec 1, 2011 at 7:43pm

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 .

Dec 2, 2011 at 1:16am

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.


Dec 3, 2011 at 4:31am

FYI this bug has been fixed in our development builds, and will be part of the next update.


You must be logged in to reply to this topic.