|
|
Jun 25, 2013 at 4:24pm
gen and History in functions
When writing GenExpr code I have found it very useful to have History operators defined in a function like so:
gran_voice(buf, chan, window, pitch, speed, grain_randomness, grain_length, phase) {
History hold_val(0);
History win_index(0);
History buf_index(0);
History rand_offset(0);
....
}
This allows for the functions to carry around an internal state and makes them somewhat quasi-closures. This makes the functions I am defining in a .genexpr library far more portable and easy to deal with. I can see in the exported C++ code the State structure contains these as fields with various numbers appended to them. It would be nice to be able to access these internal History operators in GenExpr but I can’t see a way to do this and I assume it would be difficult based on the way the exported C++ code is setup or would require functors and some changes that might slow things down. Is my assumption correct with this?
|
|
|
Jul 4, 2013 at 3:51pm
Partly. Because it is a closure, each instance of gran_voice() in the GenExpr code will create new History memory in the generated code, hence the auto-naming. However this is partly an implementation detail; e.g. in earlier implementations we generated functor structs. We want to preserve the possibility of changing the implementation in the future too: it’s not clear yet what the optimal implementation is, and thus what kind of interface it could support.
|
|
|
Jul 7, 2013 at 9:58pm
It would be nice if functions were first class values and there was a mechanism for accessing internal history objects but it doesn’t seem very compatible with the current paradigm which has the advantage of seeming to be very fast.
|
