Could we finally ditch C++ for VSTs?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

Have you explored ‘is preempting something as bad, is also a bad idea?’... English is quite a bad language, with all it’s appalling exceptions and multiple meanings to phrases. We use c++ because of the vast historical experience, and available resources. Round wheels have been around for centuries, but you wouldn’t put square wheels on your car, just to be all ‘new & modern’ and expect your car to be fast. 😀

Post

quikquak wrote: Sat Sep 21, 2019 4:36 pm Round wheels have been around for centuries, but you wouldn’t put square wheels on your car, just to be all ‘new & modern’ and expect your car to be fast.
To be fair, different types of track require different kinds of wheels. All of them are round, but slicks are not much use on railroad tracks, and narrow wheels are better in keeping the fuel consumption low compared to wide ones, which doesn't necessarily also apply to wooden cart wheels. One could argue that compiling programming languages are like different wheels, a specialized means to handle a certain set of tasks, and that the different dialects (C++, C#, D, Delphi, ...) are just like wheels with different properties. They don't necessarily all reinvent the underlying principle, but they can very well have a preferred/intended purpose or special/unique field of application that still justifies their use/existence. Having written that, personally I think that C++ is a very well fitting and performing wheel for the kind of track that is DSP, so I see no reason to ditch it.
Confucamus.

Post


Post

do whatever you want and live with the consequences/workarounds :D no customer will ever asked you with what tool you made a plugin. c++ will open up a bunch of new possibilites with c++20 and will get more mighty again with c++23. of course some consider it a bad language, well because you have to know what you're doing or else you're shooting yourself... but given that whole industries see its benefits, it might not be that bad ;-)

Post

@frizzbee Exactly!

Post

soundmodel wrote: Sat Sep 21, 2019 4:00 pm My uni courses have taught me otherwise. We have explored "why C++ is a bad language" just like some else have.
I sincerely hope you're not paying out of pocket for that course. This situation reminds me a bit of https://meyerweb.com/eric/comment/chech.html.

It took me a decade to realize that C++ is a "bad language" due to two design constraints.
- "You don't pay for what you don't use." The STL is very general not only because it needs to support all possible target platforms, but so that the optimizer is able to remove all code and bytes in memory that aren't needed in your algorithm. You can pass by either value or reference, something most languages don't let you do. Templates allow you to write a very general algorithm but allow the optimizer to compile for your specific case. This means that it's a great language for microcontrollers, where you need to minimize memory and know exactly what instructions you're compiling to. If you want to achieve something very specific in C++ for performance reasons, the language makes it possible.
- "Don't break old code." For the most part, source code written as far back as 1985 will compile with no changes. In addition to its interoperability with C, there's not much code written on this planet that won't work in your C++ application. This is a difficult constraint when designing new C++ features, but the standards committee considers this to be a primary goal.

But if you look at these constrains, you'll realize they're absolutely necessary for a DSP and application language that you won't find in too many other languages.
VCV Rack, the Eurorack simulator

Post

soundmodel wrote: Sat Sep 21, 2019 4:00 pm
whyterabbyt wrote: Mon Sep 16, 2019 9:28 am...
My uni courses have taught me otherwise. We have explored "why C++ is a bad language" just like some else have.

I believe that the future of programming is in DSLs (Domain-Specific Languages). I.e. using and developing languages that are "closely" tailored for the problem domain. The host language can be of several kind. But even for these there exists evidence that some are "better preferred by users" than some others. But I believe this "evidence-based programming language development" is a newish thing. I've been taught that for long there has existed a philosophical problem related "how to measure programming language use".
Python is a great scripting language. It has a Garbage Collector and dynamic typing. I'm sure it's great for a ton of server backend stuff and for driving AI setups with Tensorflow and whatnot. But it's not a language for developing VST plugins, and can never be unless someone comes out with a variant with no GC and no dynamic typing that compiles to native code that can be put into a DLL.

Same goes for most of the languages you've mentioned. Matlab? Can't put that in a DLL. Julia? It has a Garbage Collector (and only has had a debuggger since last May!?). Quorum? It has a Garbage Collector (it seems).

C++ might be a bad language, but it doesn't have a GC.

Post

MadBrain wrote: Sun Sep 22, 2019 5:49 am C++ might be a bad language, but it doesn't have a GC.
Technically speaking... you can use a GC with C++ if you want to, it's just that it doesn't force one down your throat. :)

Post

I find that the GC argument is sort of naive, because again my uni courses have taught me that "smart modern language developers are very aware of the problems of forced-GC". Therefore any new "good language" should have some solution to this.

This should again illustrate that there exists language designers who are "learning from historical mistakes". And therefore one should expect that "someone has improved on this idea". C++ is an old language and one of its problems is that it's at the same time old and new so it leads to "mixed standards". They can't remove something outdated, because it will break old code. They can add new, but then they bloat the language.

Post

GCs are unpredictable and basically hidden from the script author. I wouldn’t like the idea of something happening in the middle of a time crucial DSP call. There are no moments to call the GC manually, in a DSP thread.

Post

soundmodel wrote: Sun Sep 22, 2019 7:33 am I find that the GC argument is sort of naive, because again my uni courses have taught me that "smart modern language developers are very aware of the problems of forced-GC". Therefore any new "good language" should have some solution to this.
What you you mean the GC argument is naive? Tons of really smart people have tackled the GC problem for more than 2 decades now, and there has been no cure for GC pauses yet. The people behind Rust figured that this was gonna be a problem and literally tore the GC out of the language specs in version 2 before the language got popular, switching to RAII (same object lifespan method as C++) and reference counting. This is the only solution.
This should again illustrate that there exists language designers who are "learning from historical mistakes". And therefore one should expect that "someone has improved on this idea". C++ is an old language and one of its problems is that it's at the same time old and new so it leads to "mixed standards". They can't remove something outdated, because it will break old code. They can add new, but then they bloat the language.
Aside from Rust, none of these newer languages seem to be designed for the environment in which a VST runs: your code has to run from a DLL, the DAW will happily create multiple copies at the same time which can all run together at the same time on different threads (both the sound-mixing and the GUI thread). If there's any sort of global data, the multiple instances will read and write it at the same time across multiple threads and you'll have all sorts of untractable bugs and crashes due to the interactions on this partially updated global state. You can't have an external VM of any kind.

Post

MadBrain wrote: Mon Sep 23, 2019 5:08 pm
soundmodel wrote: Sun Sep 22, 2019 7:33 am I find that the GC argument is sort of naive, because again my uni courses have taught me that "smart modern language developers are very aware of the problems of forced-GC". Therefore any new "good language" should have some solution to this.
What you you mean the GC argument is naive? Tons of really smart people have tackled the GC problem for more than 2 decades now, and there has been no cure for GC pauses yet.
Strictly speaking that isn't true. It is possible to have a GC that can guarantee strict real-time operation, but the problem is that AFAIK every known such algorithm has a high mutator overhead cost, since you basically need barriers on just about every memory access. As a result, they are not particularly popular.

Post

vortico wrote: Sat Sep 21, 2019 8:56 pm
soundmodel wrote: Sat Sep 21, 2019 4:00 pm My uni courses have taught me otherwise. We have explored "why C++ is a bad language" just like some else have.
I sincerely hope you're not paying out of pocket for that course. This situation reminds me a bit of https://meyerweb.com/eric/comment/chech.html.

It took me a decade to realize that C++ is a "bad language" due to two design constraints.
There is no "perfect" language, just one that best fits your use case. Fortran is obviously the best choice here for DSP. :P

C++ (11 or earlier) isn't really a "bad" language, people just use it badly. And to fix that, C++ (14 and later) tries to prevent these same people from using it badly, but only succeeds in making the programming experience as painful as is humanly possible.

Frankly, I use C++ 11 as C-with-classes with a bit of the syntactic sugar that covers up some of the ugly C warts. I've considered using Delphi/Free Pascal, which seems like an excellent contender, but it is hopelessly wordy to me. I've considered D, but it seems it's the essentially the same as C++ in the fashion I use it, so why bother with the extra steps. Rust just annoys me for some reason, so it's still on the back burner--it may just be the Rust fanboys. :lol: I've got my eye on a couple of up-and-comers, such as Zig, but they aren't ready for primetime yet.

C++ is what we've got until Steinberg decides there's something better out there.
I started on Logic 5 with a PowerBook G4 550Mhz. I now have a MacBook Air M1 and it's ~165x faster! So, why is my music not proportionally better? :(

Post

Another language to consider is Nim which transpiles to C or C++.

https://nim-lang.org/

It reached 1.0 recently but it is pretty mature and has been in development for many years. It supports async programming, concurrency, etc, which is similar in concept to Go or Kotlin. It has C and C++ interop so it's possible to use libraries and frameworks in those languages with Nim. It's intended for high performance use cases and the garbage collector can be turned off.

There is a book by the language authors from Manning called "Nim in action" (Manning is IMO one of the most reputable companies of programming books).

https://www.manning.com/books/nim-in-action

I haven't had time to use it yet, but I'm going through the book and it looks promising. I'll have some time in a couple of weeks and will try to use it with JUCE.

Post

C++ (11 or earlier) isn't really a "bad" language, people just use it badly. And to fix that, C++ (14 and later) tries to prevent these same people from using it badly, but only succeeds in making the programming experience as painful as is humanly possible.
C++11 has many features that help creating idiot-proof, safe and automagical libraries which handle all the typing, safety checks and boilerplate code.
However, all this comes naturally in more moderns languages and is transparent to their user. It's not the case in C++11, however, since it still maintains backward compatibility with original language that is 47 years old.
Blog ------------- YouTube channel
Tricky-Loops wrote: (...)someone like Armin van Buuren who claims to make a track in half an hour and all his songs sound somewhat boring(...)

Post Reply

Return to “DSP and Plugin Development”