KVR Audio

soundmodel · Post by **soundmodel** » Sun Sep 15, 2019 5:08 pm

Could we finally ditch C++ for VSTs?

Upon doing uni courses around DSP, I tend to see quite few mentioning of C++. It's usually Python or Matlab and then, if there's a need for real implementation, then they have started to rave about Julia, Quorum and the sorts.

I tend to find that the developments in programming languages ought to be reflected to application domains and then it seems like keeping using old technology just disallows one from taking advantage of new developments.

But what kind of process would this kind of transition be? Does Steinberg or someone necessarily have to report their libraries? Or is it possible to approach this using some "wrapper"?

I think having more elegant syntax makes DSP algorithms noticeably easier to understand and share.

quikquak · Post by **quikquak** » Sun Sep 15, 2019 6:12 pm

When you say "we" do you mean - "I wanna use what I got schooled in - WAAAH!" !

C++ is chosen because it's fast AND flexible. So it became popular as the professional's choice in DSP and the game dev community.

C++ can be very elegant, and yes, it's sometimes abstracted to hell by idiots, but it doesn't have to be. I personally like it.
It's not really a surprise that a popular language becomes the go-to language - for now...

I personally would love to use C# but it's just not fast enough, yet.

Jafo · Post by **Jafo** » Sun Sep 15, 2019 6:59 pm

Actually, there are quite a few other options in daily use. I've seen plugs coded in Delphi, Java, and C#; and there have been plugs that use Lua and Ruby for live coding. Then there's Reaktor, SynC, SynthEdit, and SynthMaker/Flowstone. Oh, and Faust, SuperCollider, Max/MSP and even more obscure environments. However, C++ (or at least C-with-Classes) easily outperforms all of them, so it's not going away.

Obsolete236871 · Post by **Obsolete236871** » Sun Sep 15, 2019 7:13 pm

For straightforward programming languages for the audio DSP domain take a look into one of these two options: a) FAUST and b) the newly anounced SOUnd Language (SOUL) by JUCE / Roli.

soundmodel · Post by **soundmodel** » Sun Sep 15, 2019 7:23 pm

Izak Synthiemental wrote: ↑Sun Sep 15, 2019 7:13 pm For straightforward programming languages for the audio DSP domain take a look into one of these two options: a) FAUST and b) the newly anounced SOUnd Language (SOUL) by JUCE / Roli.

FAUST is possibly reasonably elegant, since it's functional, but lately I've started to think as to whether SOUL is "just another Reaktor (i.e. a musical DSP -specific language)". I don't like the idea of "musical DSP -specific language", because I think musical DSP is not a "proper subdomain" in order to require a DSL, rather than "an extra library".

My idea is not so much in creating new languages, but if there's a language where one already does e.g. DSP work, say Julia, then wouldn't it make sense to write DSP plug-ins using that same language?

One could argue e.g. that:

-Making a language do too many things could bloat the language.

But on the other hand:

-Using similar language for many things would offer less translating between "different endeavors".

On the other hand, if the language doesn't take long to learn (some languages take, such as Haskell), then jumping from one to another might not be that much of a hassle.

The main argument in this thread is that I think that C++ definitely isn't a very elegant language. It has a lot of redudant syntax.

quikquak · Post by **quikquak** » Sun Sep 15, 2019 7:26 pm

FL Studio was (is still?) written in Delphi.

Jeff McClintock · Post by **Jeff McClintock** » Sun Sep 15, 2019 8:49 pm

>Actually, there are quite a few other options in daily use. ... there's Reaktor, SynC, SynthEdit, and SynthMaker/Flowstone.

All coded in C++ BTW

mystran · Post by **mystran** » Mon Sep 16, 2019 12:11 am

Most general-purpose managed languages have garbage collectors that don't provide any real-time guarantees and for serious audio programming that is simply a "no go" irrespective of the actual performance of any given language. If you want your plugins to be safe for live performance, you really don't want to gamble with any of that. This really the main reason C++ remains the king of the hill.

Forgotten · Post by **Forgotten** » Mon Sep 16, 2019 1:13 am

Also, it's pretty easy to embed inline assembly code into C++ which I would imagine would be very useful when trying to optimize audio processing.

mystran · Post by **mystran** » Mon Sep 16, 2019 1:55 am

Forgotten wrote: ↑Mon Sep 16, 2019 1:13 am Also, it's pretty easy to embed inline assembly code into C++ which I would imagine would be very useful when trying to optimize audio processing.

Inline assembly with C++ is rarely a good idea these days (at least on mainstream hardware), since compilers these days are quite decent at low-level optimization and intrinsics let you write SIMD code directly from C++ while still leaving register allocation and instruction scheduling/selection to the compiler. Last I checked, MSVC didn't even support inline assembly for 64-bit targets, although you could certainly still link separately compiled assembler files if you really wanted... but honestly it's rarely worth it.

BertKoor · Post by **BertKoor** » Mon Sep 16, 2019 6:41 am

Python & Matlab are great for prototyping & education, but not so much for production-ready stuff where efficiency is more important than fast bashing out a concept to see whether the idea works as expected.

camsr · Post by **camsr** » Mon Sep 16, 2019 7:00 am

Unless you really need to use inline assembly, because the language itself does not provide a method of using a platform-specific instruction, it's best to be avoided. That does not include using an API either, for example try using the rdtsc instruction without inline assembly, it may appear after a call through the api and some odd levels of indirection, but that's not necessary. But save some time and let the compiler figure most stuff out, that's what it's made to do.

whyterabbyt · Post by **whyterabbyt** » Mon Sep 16, 2019 9:28 am

soundmodel wrote: ↑Sun Sep 15, 2019 5:08 pm I tend to find that the developments in programming languages ought to be reflected to application domains

You 'tend to find' that something ought to happen?

Erm, that sounds more like opinion than a solid technical reason. What 'developments' that cant be leveraged in C++ impact on software plugins?

and then it seems like keeping using old technology just disallows one from taking advantage of new developments.

You really need to provide evidence of that. Lisp and Prolog still have a very significant toehold in AI development, for example, and Python, which seems to be one of the most common languages is nearly 30 years old.

C++ is perfectly suitable for VST development. Argument smacks a little bit of 'the world should adjust to me.'

DJ Warmonger · Post by **DJ Warmonger** » Mon Sep 16, 2019 9:48 am

BertKoor wrote: ↑Mon Sep 16, 2019 6:41 am Python & Matlab are great for prototyping & education, but not so much for production-ready stuff where efficiency is more important than fast bashing out a concept to see whether the idea works as expected.

Exactly that. Every language has its purpose.

You can create great plugin in Python I suppose, but then hundreds of people around the world can create plugins in C++ which are many times faster. Or, from user's perspective, yours is slower.

The possible alternative to C++ is Rust, which is however not conceptually different being, it's just streamlined for modern patterns and hardware.

BertKoor · Post by **BertKoor** » Mon Sep 16, 2019 10:35 am

DJ Warmonger wrote: ↑Mon Sep 16, 2019 9:48 am You can create great plugin in Python I suppose

Given that Python is interpreted instead of compiled (unless you cross-compile it with e.g. Cython) and depends on garbage collection to clean up unreferenced objects, I doubt it's easy...