Declarative, non-intrusive, compile-time C++ reflection for audio plug-ins

What are some things this can be used for? From a short skim this seems like a way to make sharable, tweakable effects and patches for any OS. Stuff that historically soundflower could be use for?

> Here the idea is to write the algorithms in a way that is more future-proof

More baroque, for sure. More future-proof? Only if this is the one true form of reflected code that gets adopted.

> This way the algorithms will still be useful in 10 years when everyone has moved to API N+1

Actually, this way algorithms are not useful today since nobody writes them this way, and in 10 years, whoever writes this way right now will probably have moved on.

Now, if some small community (like C++-reflection-and-audio-buffs) commits to this, then maybe it makes sense for them. But not generally. General reflection (not to mention runtime reflection) is probably the way to go.

> More baroque, for sure. More future-proof? Only if this is the one true form of reflected code that gets adopted.

ah, actually not :) the library tries to do things in two steps in many places:

1/ map the user's code to a proxy depending on which concepts it conforms to: for instance whether your audio processing function is written per-sample (that's still in progress tho):

    float operator()(float input) { return input * 0.5; }

or per-buffer:

    void operator()(float** inputs, float** outputs, int frames) { for(each channel, each sample) { ... } }

2/ the back-end accesses the class through these proxies to do whatever it needs to do.

this means than if tomorrow we get reflection and metaclasses (I hint to this in the readme), and that we can write the "ideal" struct which (to me) would look like

    struct my_effect { 
      [[name: "Main inputs"]]
      audio_input main_input;
      [[name: "Main outputs"]]
      audio_output main_input;
      
      [[range: {20, 20000}]]
      [[unit: hertz]]
      slider frequency; 

      // will create an appropriate message in max / pd with the name some_function
      void some_function(int, std::ranges::view> list_of_stuff);

      auto operator()(std::floating_point auto in) { return in * gain; }
    };

the only thing that one will have to do is map the new "shape" in these proxies (which are as far as possible doing their stuff at compile-time) and all the existing backends will keep working with the algos defined in the better way.

of course the existing algorithms will stay uglier, but they'll also keep working with new environments (and, as far as possible, without a runtime perf. hit)

> General reflection (not to mention runtime reflection) is probably the way to go.

yes, we all want that !

Going to ask some really stupid questions, apologies in advance:

This is mindblowing work. I'm having some trouble wrapping my head around all of it. Will lead with the context that:

  A) I am not very familiar with audio programming specifics, or DSP at all. I have done some things with VST2 + VST3, and looked into LV2.

  B) I have very little background with C++

I am curious:

  1. Is this targeted more towards the DSP and algorithm side of audio plugin development, or is there interest/use for the plugin side too (IE, generating VST/LV2 compatible interfaces)?

  2. Would a byproduct of this be that you would be able to implement functionality + interact with C++ classes from other languages? Or generate C ABI's? I see the note: "Automatically generate Python bindings for a C++ class"

I ask about the second one because I have been trying to work towards getting a C ABI for VST3 so that language bindings can be codegen'ed. I know VST3 works through COM so you can use that, but the alternative is to emulate the VTable layouts in C structs. This can make it easier than implementing COM in a language.

-----

Edit: I also wanted to say that when reading your blogpost, the way you write C++ is very easy to understand. Not sure if it's a stylistic thing or a purposeful choice. I usually have to spend a second reading C++ code to comprehend it, but in your snippets, I was able to (mostly) grok it first pass.

Same for the example code in the repo.

That "tomorrow" will be way beyond C++26, as per latest news in feature adoption.