What are the most important parts of C++ for coding plug-ins?

[muzicxs]

but the event dispatch in general is the big one: you need a toolkit that can work purely based on standard events, dispatched by a standard event loop that is not part of the plugin itself... and it must not step on the toes of anything else in the process.

Let me first thank you for your help! It's really appreciated.

Do I understand it correctly that the host "feeds" the plugin with events related to the GUI, therefore you want it not to have its own event loop? Or in other words, the plugin is the slave and the host the master? I'd never have guessed this relationship on a GUI-level, to be honest. For receiving audio and MIDI I would have guessed that the host is the master, but not for GUI-events.

[mystran]

Do I understand it correctly that the host "feeds" the plugin with events related to the GUI, therefore you want it not to have its own event loop? Or in other words, the plugin is the slave and the host the master? I'd never have guessed this relationship on a GUI-level, to be honest. For receiving audio and MIDI I would have guessed that the host is the master, but not for GUI-events.

That's how it works on Windows/macOS at least... sort of. I would not necessarily think of it as a "master/slave" type of deal, because event loops aren't really like that; for all intents and purposes a "normal" event loop treats every event exactly the same independent of whether it's directed to a host or a plugin window/view. Rather there is a message queue, typically on a per-thread basis and the OS puts any events into this queue, with a field that indicates the relevant window (or NSView in case of macOS).

The GUI thread then essentially sits on the event loop and does nothing except sends events. On Windows this looks something like this (this is sort of minimal, there might be a few other things like TranslateMessage, but a plugin really should work with a loop like this):

Code: Select all

    MSG msg;
    while(GetMessage( &msg, 0, 0, 0 )) // GetMessage only return 0 when next message is WM_QUIT
    {
        DispatchMessage(&msg);
    }

On macOS this is even more boring:

Code: Select all

   [NSApp run]; // this does not return until the application exits

The key though is that because this thing sits at the very bottom of the GUI call stack (which is host application code), whatever toolkit you use must be able to function completely based on events and not insist that it has control of the event loop itself.

[Nerantzis]

Very interesting topic. For VST work, the C++ basics matter more than people think. If you focus on classes, memory handling and basic DSP math, you’ll already be ahead of a lot of beginners. The rest you pick up naturally once you start building things.

[steven961302]

Standard C++ tutorials often teach things that are 'illegal' in a VST's audio thread (like heap allocation or mutexes). I’d recommend spending time understanding Templates and Data Structures (like Circular Buffers). These are the bread and butter of DSP. Don't worry about learning every corner of the C++ standard library (STL) yet; focus on what makes code fast and predictable

[muzicxs]

Wouldn't plain C or Zig be an option instead of C++?

[mystran]

Wouldn't plain C or Zig be an option instead of C++?

Yes, but if you're asking the question then the answer is really more of a no... because in order to actually use something else besides C++ you should already understand how things work on a low level and then the whole question no longer makes much sense.

If you're writing in C++ and hit a problem, there's tons of resources around and if you ask on forums, almost anyone will be able to help. If you're writing in something else that very few people use, then you will find that finding help is going to be significantly more difficult. For the same reason, C is also probably a better choice than Zig.

[muzicxs]

Wouldn't plain C or Zig be an option instead of C++?

Yes, but if you're asking the question then the answer is really more of a no...

I understand and appreciate the thought behind your answer, but in this case, I'm curious as why people pick C++ over a much simpler language like C. Is the object-oriented nature of C++ beneficial for audio processing? Are certain libraries build in C++ a necessity? I'm asking from the perspective of a fellow programmer, not someone who just started out and has no idea what for-loops are.

I wonder, because from what I've researched so far is that the true difficulty seems to be DSP, not the language responsible for producing the binary (e.g. C++).

[ToneCarver]

Wouldn't plain C or Zig be an option instead of C++?

Yes, but if you're asking the question then the answer is really more of a no...

I understand and appreciate the thought behind your answer, but in this case, I'm curious as why people pick C++ over a much simpler language like C. Is the object-oriented nature of C++ beneficial for audio processing? Are certain libraries build in C++ a necessity? I'm asking from the perspective of a fellow programmer, not someone who just started out and has no idea what for-loops are.

I wonder, because from what I've researched so far is that the true difficulty seems to be DSP, not the language responsible for producing the binary (e.g. C++).

I think it is a matter of balance between language simplicity (C) and language capability (C++). Anything coded in C++ could be coded in C as well, but C++ provides programming abstractions (OOP, polymorphism, templating, encapsulation, etc.) that can make the lift easier (at least for me). I suppose any language could be used really, since all high level languages are just abstractions on the assembly code (which is an abstraction on the machine microcode). It boils down to finding and using the right tool for the job, and the "right" tool can vary depending on a programmers experience, familiarity, and dependency on 3rd party integrations required.

[mystran]

Wouldn't plain C or Zig be an option instead of C++?

Yes, but if you're asking the question then the answer is really more of a no...

I understand and appreciate the thought behind your answer, but in this case, I'm curious as why people pick C++ over a much simpler language like C. Is the object-oriented nature of C++ beneficial for audio processing?

Everything in your audio code, including the plugin itself (you do want multiple instances, right?) is effectively an object, whether you're writing in C++ or something else... and then half of your plugin is user interface which is well known to be pretty much the poster child of OOP. You're going to be doing that in C anyway, so why not let your compiler help you.

You should not think of C++ as a language that forces you to write your code one way or another. It doesn't. You can take 99% of all C code and (with some trivial tweaks in some cases) it'll compile as C++ just fine... so C++ literally just gives you more tools to avoid writing as much boilerplate.

In my book, pure C has literally one advantage over C++ and that's when you write a library, if it exposes a C-interface it'll be easier to interface from any random language. That's it. For everything else, when you actually want to get things done... C++ is superior. The beauty of C++ is that it gives you more features, but you don't actually need to use them... but a lot of those features are quite useful in practice, particularly when it comes to reducing boilerplate which is sooner or later turns into a maintenance headache.

[Viga]

Well said!