More complex example than the WDF model ?

Started by sletz, Aug 24, 2023, 01:21 PM

paolo

There is some initial implementation here: https://github.com/paolomarrone/Zampogna/blob/dev/src/builtin.crm
(temp and not tested yet) that could give you an idea.

Quote from: sletz on Aug 28, 2023, 10:25 AMAbout delays, in case it helps, in Faust:
- we have a general delay operator https://faustdoc.grame.fr/manual/syntax/#time-expression_1
- which is part of the box API (https://faustdoc.grame.fr/tutorials/box-api/#defining-a-delay-expression) and then signal API (https://faustdoc.grame.fr/tutorials/signal-api/#defining-delayed-signals)
- so that the user does not have to explicitly think about how the delay line is finally implemented by the compiler, but then can possibly control it, if needed, for specific CPU/memory optimisation purposes. This allow for nice optimisation capabilities we discovered over the years see: https://faustdoc.grame.fr/manual/optimizing/#delay-lines-implementation-and-dsp-memory-size

Thank you for this. Might be useful.
Do you allocate memory dynamically too?


sletz

No all memory size is computed at compile time and allocated at DSP construction time.

stefano

Quote from: sletz on Aug 28, 2023, 10:25 AMAbout delays, in case it helps, in Faust:
- we have a general delay operator https://faustdoc.grame.fr/manual/syntax/#time-expression_1
- which is part of the box API (https://faustdoc.grame.fr/tutorials/box-api/#defining-a-delay-expression) and then signal API (https://faustdoc.grame.fr/tutorials/signal-api/#defining-delayed-signals)
- so that the user does not have to explicitly think about how the delay line is finally implemented by the compiler, but then can possibly control it, if needed, for specific CPU/memory optimisation purposes. This allow for nice optimisation capabilities we discovered over the years see: https://faustdoc.grame.fr/manual/optimizing/#delay-lines-implementation-and-dsp-memory-size

In our case we also opted for explicit memory control to allow for multi-tap delays, as we didn't find a way to implement them with a regular block-like operator (of course we could special case it, but that would complicate things).

I think most optimizations you have could be directly implemented in Ciaramella as it is, but probably it would require quite some effort when designing the include/import mechanism (which we haven't done yet).

Anyway, that's excellent food for thought. Thank you.
Personal website: https://dangelo.audio/