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
[1]: https://docs.cycling74.com/max7/vignettes/gen_overview
--
Ho cambiato l'indirizzo email in [email protected] . Se non รจ un
problema, scrivimi a questo nuovo indirizzo email.
I changed my email address in [email protected] . If it is ok for
you, please write me to this new email address.
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
