genexpr oddity

    Nov 29 2011 | 7:20 pm
    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 01 2011 | 7:43 pm
      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 02 2011 | 1:16 am
      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 03 2011 | 4:31 am
      FYI this bug has been fixed in our development builds, and will be part of the next update.