Could we finally ditch C++ for VSTs?

DSP, Plug-in and Host development discussion.
quikquak
KVRian
605 posts since 6 Aug, 2005 from England

Post Sat Sep 21, 2019 8:36 am

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. 😀

User avatar
Rockatansky
KVRist
328 posts since 3 Jun, 2017

Re: Could we finally ditch C++ for VSTs?

Post Sat Sep 21, 2019 8:53 am

quikquak wrote:
Sat Sep 21, 2019 8:36 am
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.

quikquak
KVRian
605 posts since 6 Aug, 2005 from England

Re: Could we finally ditch C++ for VSTs?

Post Sat Sep 21, 2019 9:07 am


frizzbee
KVRist
254 posts since 11 Jan, 2015

Re: Could we finally ditch C++ for VSTs?

Post Sat Sep 21, 2019 9:13 am

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 ;-)

quikquak
KVRian
605 posts since 6 Aug, 2005 from England

Re: Could we finally ditch C++ for VSTs?

Post Sat Sep 21, 2019 9:20 am

@frizzbee Exactly!

User avatar
vortico
KVRist
308 posts since 19 Jul, 2008

Re: Could we finally ditch C++ for VSTs?

Post Sat Sep 21, 2019 12:56 pm

soundmodel wrote:
Sat Sep 21, 2019 8:00 am
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 open-source virtual modular synthesizer

MadBrain
KVRian
971 posts since 1 Dec, 2004

Re: Could we finally ditch C++ for VSTs?

Post Sat Sep 21, 2019 9:49 pm

soundmodel wrote:
Sat Sep 21, 2019 8:00 am
whyterabbyt wrote:
Mon Sep 16, 2019 1: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.

mystran
KVRAF
5492 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Could we finally ditch C++ for VSTs?

Post Sat Sep 21, 2019 11:20 pm

MadBrain wrote:
Sat Sep 21, 2019 9:49 pm
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. :)
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

soundmodel
KVRian
686 posts since 28 May, 2010 from Finland

Re: Could we finally ditch C++ for VSTs?

Post Sat Sep 21, 2019 11:33 pm

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.

quikquak
KVRian
605 posts since 6 Aug, 2005 from England

Re: Could we finally ditch C++ for VSTs?

Post Sun Sep 22, 2019 12:00 am

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.

MadBrain
KVRian
971 posts since 1 Dec, 2004

Re: Could we finally ditch C++ for VSTs?

Post Mon Sep 23, 2019 9:08 am

soundmodel wrote:
Sat Sep 21, 2019 11:33 pm
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.

mystran
KVRAF
5492 posts since 12 Feb, 2006 from Helsinki, Finland

Re: Could we finally ditch C++ for VSTs?

Post Mon Sep 23, 2019 9:57 pm

MadBrain wrote:
Mon Sep 23, 2019 9:08 am
soundmodel wrote:
Sat Sep 21, 2019 11:33 pm
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.
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

User avatar
syntonica
KVRian
545 posts since 25 Sep, 2014 from Specific Northwest

Re: Could we finally ditch C++ for VSTs?

Post Sun Oct 06, 2019 3:04 pm

vortico wrote:
Sat Sep 21, 2019 12:56 pm
soundmodel wrote:
Sat Sep 21, 2019 8:00 am
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.

pierb
KVRist
51 posts since 28 Oct, 2010 from Mexico

Re: Could we finally ditch C++ for VSTs?

Post Fri Oct 11, 2019 10:27 am

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.

User avatar
DJ Warmonger
KVRAF
3463 posts since 7 Jun, 2012 from Warsaw

Re: Could we finally ditch C++ for VSTs?

Post Fri Oct 11, 2019 10:44 am

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.
http://djwarmonger.wordpress.com/
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(...)

Return to “DSP and Plug-in Development”