On Wednesday, 4 May 2022 at 18:14:21 UTC, user1234 wrote:

I have never tried audio morphing plugins, but it sounds fun! A long time ago I read a paper that decomposed sound into noise and sinus components and used that for morphing between instruments or spectrally changing the character of an instrument. I cannot find the paper… but it seemed to use the same principles as Melodyne.

On Wednesday, 4 May 2022 at 20:31:52 UTC, Ola Fosheim Grøstad wrote:

seriously ?

On Wednesday, 4 May 2022 at 20:48:12 UTC, user1234 wrote:

I am interested in the ideas, not really the products. :-) For hobby music I actually am most happy if I get to create all the sounds from scratch using basic math + flangers + reverb, but it is time consuming…

On Thursday, 5 May 2022 at 23:06:26 UTC, Walter Bright wrote:

Is CTFE really that useful? Generating code as a part of the build process has been in use since a very long time ago. Any programming languages (perl, python, php, ...) or tools (bison, flex, re2c, ...) could be used for this. Yes, the build process becomes a bit more complicated, because you suddenly have more build dependencies and more complicated build scripts or makefiles. Still it's not a rocket science. Everything is pretty easy to use and understand.

CTFE allows to to cut some corners and move this complexity into a compiler. The upside is that we don't need advanced build scripts. But the downside is potentially slower compilation (especially with the interpreting approach), which is also too obscure and hard to notice and fix. Additionally, can CTFE be used to sniff some passwords from my system and embed them into a compiled binary? Now we got some security concerns on top of that.

As for the other languages implementing CTFE, my understanding is that compiler people just generally have to do something to keep the ball rolling and have themselves entertained and employed ;-) The features themselves may be useful or they may be just gimmicks. Only time will tell.

At the end of the day, D language happens to be unpopular. CTFE doesn't look like a panacea.

On Friday, 6 May 2022 at 05:58:37 UTC, Siarhei Siamashka wrote:

That's the point. It reduces build complexity in a disruptive way.

You have to include your build tool invocation and development time

We are now deep in "whataboutism-fallacy" territory here, aka as clutching at straws to win he last word in a debate. The same security issue (I would even say, worse) with external build tools generating code.

No-one ever said it was (this is another rhetorical fallacy called strawman).

On Friday, 6 May 2022 at 06:18:08 UTC, Patrick Schluter wrote:

My point is that CTFE actually increases the complexity and moves it somewhere else in a somewhat obscure way. It's one of the zillions of extra features that make the language spec bloated and difficult to learn.

Yes and no. What really matters is the transparency and simplicity.

For example, I can have a tool which calculates Pi number with high precision. Then I bundle this tool as a part of the project and simply use the computed constant in the source code. This extra tool is very visible in the project structure and there's nothing obscure about it. But with the CTFE approach, somebody may be tempted to do the expensive Pi constant computation every time at the compilation time. And this may be hidden somewhere deep in the source code in a much less visible way. Looks like such feature makes it too easy to shoot yourself in the foot.

Uhm? Sorry? Are you saying that it's me who is clutching at straws? This whole thread is about what makes D language unpopular. People seem to be clutching at straws to claim that the D language is great, but somehow the rest of the world just doesn't get it.

The setup with external build tools is surely much easier to understand and review.

On Friday, 6 May 2022 at 05:58:37 UTC, Siarhei Siamashka wrote:

I find it to be useful for parametric types that initialize constant tables. If the program does constant lookups those values can be turned into constants known at compile time. Or like in the example I gave further up where you compute the length of delay lines at compile time so that you can make sound effects allocation free.

In general CTFE would be most powerful in combination with AST manipulation to construct new types. D uses string mixins for this puropose which is macro-like in nature, so this partcular use case for CTFE is macroish IMHO.

For code gen I actually think having a Python script can lead to more readable code, because then you see the generated code as part of your program and debugging is straight forward. Such code is seldom modified in my experience so I sometimes just inline the Python script as a comment.

So overall, for me CTFE is most useful for computing constants.