3 ms·
> 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
by jcelerier 5y ago
> 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<std::variant<float, int>> 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 !
- pjmlp 5y agoThat "tomorrow" will be way beyond C++26, as per latest news in feature adoption.
- tialaramex 5y agoI'm going to assume you wanted to declare an audio_output named main_output here and not re-declare main_input which presumably doesn't compile in this hypothetical future C++ dialect. In the audio space I can imagine Concepts' Duck-typing is probably fairly effective for this work, you're rarely going to have something that looks like this flavour of duck but is not, in fact, a duck. It has been many years since I wrote LADSPA plugins, but there I'd guess the only confusion might be that there's deliberately no API difference between PCM data and CV, a reasonable strategy if you're building a modular synth but probably not what you want to listen to as output. Such differences are expressed only in metadata. On the other hand, the same thing that presumably made this an attractively simple project for C++ 20 features also makes its practical utility very limited. Over the years what seems to matter to musicians is mostly the packaging, not the algorithms. The same exact algorithm exists for twenty years and then somebody famous calls it "Wonky-smog-burble", paints it fluorescent purple and presents the control parameter as an integer between 3 and 17 - suddenly it is this week's hot new sound. Which is fine of course, but the API doesn't matter at all to such fashions.