Pd-list April 2018

pd-list@lists.iem.at

62 participants
74 discussions

sparse considerations about jit_expr (was: jit_expr 0.1: Just in time expr/expr~/fexpr~)
by mario buoninfante 01 Apr '18

01 Apr '18

Hi Marco, as I said before I really like the idea of introducing a just in time compiler, and I like the ideas you presented here. the only thing I'd say is that I'd avoid introducing in Pd a pseudocode (max/gen~ style). in my opinion using (if possible) an existing scripting language (Lua, Python, etc ) would be a better option. then, about having the possibility to write sample level patch in an optimized way sounds amazing. I'm just wondering if it wouldn't be a better idea trying to better integrate Faust. my only concern is about maintainability of this new object family, JIT (in case we're talking about a specific object family). Faust is already out there and works pretty fine plus has an active and big community that constantly works to improve and update it. last but not the least, multithreading is obviously a good thing, but honestly do we really need to have something similar to what you described? don't get me wrong, the idea is cool and I only want to discuss these ideas, not criticize them. but personally, and of course I know everyone has different approaches and different needs, I think there's still a lot to explore before "moving to a multithreading dimension". also if it's a totally different situation (different hardware and programming language), I keep thinking about most of the commercial products, musical instruments (also the most complex) that are single thread based. mine of course are just thoughts. cheers, Mario

2 1

add inlets to [ctlin]
by mario buoninfante 01 Apr '18

01 Apr '18

Hi I0hannes, I totally agree with you about "premature optimization", but I'm pretty sure as well you agree we're not talking about GOTO statements here :D cheers, Mario

1 0

add inlets to [ctlin]
by mario buoninfante 01 Apr '18

01 Apr '18

Hi I0hannes, I'm with you, we are not talking about the most important improvement ever, but honestly still it is an improvement, and I can't see why don't do it :D I know that Pd could perfectly deal with tons of MIDI messages at time, but it's not only matter of dealing with them, but also the way it does it. the talking piano is really cool, I didn't know it. but it doesn't look like "performances" are really important in this situation (it's not a kind o f live processing integrated into a most complex system where time stuff matters), otherwise I'm pretty sure an improvement on [ctlin] would be really appreciated :D kiddin' cheers, Mario

1 0

sparse considerations about jit_expr (was: jit_expr 0.1: Just in time expr/expr~/fexpr~)
by Marco Matteo Markidis 01 Apr '18

01 Apr '18

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 mm.markidis(a)autistici.org . Se non è un problema, scrivimi a questo nuovo indirizzo email. I changed my email address in mm.markidis(a)autistici.org . If it is ok for you, please write me to this new email address.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list April 2018