Best practices converting large gen patches to GenExpr / codebox code?

No worries, Raja, you've been very helpful. In fact your comment above made me do some more research on the forum on this subject, which I believe is quite helpful in general.

I think we have been trying to explain an aspect of GenExpr code which Graham Wakefield (the designer of Gen) refers to as 'lexical instancing' -- (He expands on this concept in the forum three times, just search for 'lexical instancing'). I'll quote them partially here because they kind of make more sense together:

In this post, responding to the question "Please can you help me understand how functions work in FOR loops?"

It's "lexical instancing". That is, if you defined a function "foo", then each instance of foo() in your code implies an instance of any state foo requires (including History, latch, sah, phasor, accum, etc.). So calling foo(foo(foo(foo(x)))) creates four independent instances, but below [in a for loop] is only one instance, because the text "foo" appears only once.

and further down

Yes you can use functions in for loops, but you have to bear in mind the 'lexical instancing' issue regarding state. That is, a function that declares its own state (like History) or which uses stateful operators (like cycle, phasor, etc.) will share that state over each iteration of the for loop. Which might or might not be what you wanted.

As a direct response to this post, LARME makes the following statement:

It's a little bit tricky because a function may not use History or phasor explicitly but instead call functions that do so. Hence you need to make sure all functions in the chain of invocation is "clean" of state, am I right?

To which Graham says "Correct". So basically one needs to make strict distinction between 'stateful' functions which have to be treated specially because of 'lexical instancing' and 'pure' or stateless functions.

In this post, Graham provides an example of a 'stateful' function which creates its own state in each call:

I believe the equivalent genexpr is the following. This compiles and appears to have approximately the correct logic.

ffjk4027(clock) {
    History state;
    History buf;
    
    if (buf < 0 && clock >= 2.5) {
        state = !state;
    }
    
    buf = clock;

    if (state) {
        return 4;
    } else {
        return -4;
    }
}

(One caveat however is that the use of static variables in functions like the above code is that this variable will be shared between *all* calls of the function, which is not the case in Gen. Every lexical instance of the call to ffjk4027() in gen will create a new state/buf to go with it. If this isn't what you need, pass the History objects in as arguments to a function instead. But I'm guessing that the postfix "4027" means that this code was generated for single call, which means you don't have to worry.)

I wasn't aware that one can pass history objects as arguments.. Good know (-:

In the final and most recent post on 'lexical instancing', Graham gives some practical method on how to pass state between functions, which I found quite informative.

So, the example you give here...

a=biz(0,blam=4); // returns 4
b=biz(0); //returns 0 even after calling above line

...catches one of the subtle things about genexpr, which is that operations are 'lexically instanced'.
I think it might be easier to consider from the perspective of cycle. Roughly speaking cycle could be implemented like this:

mycycle(freq) {
History phase;
phase = wrap(phase + freq/samplerate, 0, 1);
return cos(twopi * phase);
}

Now, if you want to make a chord of sinewaves, you can write this:

out1 = mycycle(100) + mycycle(150);

Both of these phasors have internal state (the History phase), each of which is independent of each other. Behind the scenes, each time you write `mycycle()` you are creating a `History phase` for that instance, which is retained over time -- it is "stateful" in a way that e.g. `add()` isn't.

Your `biz()` function is also stateful in this way, because of the `Param blam`. So each time you write `biz()` in the code, you create a new instance of the `Param blam` associated with it. This `Param blam` remembers its value for each invocation of its particular `biz()` over time. But if you write `biz()` twice, you get two `Param blams`, one each.

If we didn't do it that way, then `mycycle(100) + mycycle(150)` would not create a chord, instead it would create one oscillator with a frequency of 250Hz.

So, the state *inside* a function is "lexically instanced": there's a new indepenent instance of that internal state for each time you *write* a call to the function.
If you want to share state between separate function calls, you will have to pass that state in to the function from outside. E.g.:

biz(poop, blam) {
return poop + blam;
}
History blam(7);
out1 = biz(30, blam) + biz(30, blam);
Or, this:
biz(poop, blam) {
return poop + blam;
}
superbiz(poop) {
Param blam; // this param shared by both biz's:
return biz(poop, blam) + biz(poop, blam);
}
// we only write `superbiz` once,
// so there's only one instance of its internal state `Param blam`:
out1 = superbiz(30, blam=7);

Note that you can also pass buffers etc. into functions in this way.

Hope that makes it clear!

Much clearer now. Now back to the drawing board.

S