Dear list,

if this is stable, wouldn't it be a nice idea to propose it as an update to

the expr~ family of objects? since it is basically an optimized clone?

basically it is an optimized clone, but we have to consider the introduction of several (and heavy: llvm one for all) dependencies before include it in the pd release.

correct me if I'm wrong, but that means with this tool we now have something like gen~ in Max

i think that the introduction of a compiler could be usefull for the introduction of a scripting language in pd that can work at the three different time levels present in pd (control, audio and sample rate). for example, in pic1 taken from 1 we can see a gen~ patch. so i think that jit_expr (and in general expr family) can read a text file, like the right one in picture, and interpret it. in this case, one can avoid to write externals and use jit_expr to compute the perform method. considering the case of a noise generator, one in principle can have this pseudocode: static int val; $y1 = ((float)((val & 0x7fffffff) - 0x40000000)) * (float)(1.0 / 0x40000000); val = val * 435898247 + 382842987; the pseudocode i wrote is just a mix of usual expr syntax and usual C syntax plus the problem of local variables where i use the static word.

btw, I know there's Faust that works with Pd

the introduction of a jit compiler is usefull to faust-ize pd, in the sense that optimizing [fexpr~] several filters that usually are done in faust can be done in pd incrementing the possibility of using small block size.

The name collision is unfortunate but "jit" very accurately describes what is happening.

honestly i do not like the namespace in pd, but i find this very usefull to switch from expr family to jit_expr.

a final consideration about jit compilation: from my understanding of multithreading in computer music, not so much apart [pd~] can be done without breaking determinism. from one hand i see the possibility to introduce a steal working scheduler that breaks the dsp graph in sub-graphs and distribute them to threads (and divide some non-real time safe computation between threads, like soundfiler object and in general array operation); on other hand the possibility to jit-compile all the dsp graph is very interesting because it should leave all the black magic to the compiler and optimizing the patch reduces the need of parallelization. finally a combination of jit-compilation plus automatic parallelization would put this conversation on the heaven of computer music parallelization :)

best, marco