Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 36 posts

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

#21

Post by jcelerier »

Negitivefrags wrote: post #12

There are examples here of making objects that will be reflected, but no examples of what it's like to consume those objects. It would be nice if there was an example of that too.

> but no examples of what it's like to consume those objects.

I'm not sure I understand: the whole idea is that since the objects are just C++ structs, to "consume" them from some C++ program would just mean including the file and using it.

Otherwise, if you want to know how you can do similar reflection on it (for instance to generate an UI from any of those processor) the simplest example is the python binding, the meat of it fits in ~100 lines of code:

https://github.com/celtera/avendish/blob/main/src/python/pro...

if that is what you mean, then yeah what I plan to do is to write some documentation to explain the techniques and reflection API

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

#22

Post by gavinray »

jcelerier wrote: post #20
drmr wrote: post #19

Earlier quoted context omitted.

Re 1: Why not create a DPF wrapper for this and have DPF create the ladspa/dssi/vst2/vst3/lv2 for you? -> https://github.com/DISTRHO/DPF

I had looked into it ! but it seemed that making a DPF plug-in involved a lot of boilerplate, while I really wanted to do something where I can just include a couple headers and get going, without any particular compilation hassle (the whole library is header-only as it is pretty much entirely templates).

This is the absolute worst part of VST3. These 2 soul-crushing lines in the build file:

https://github.com/steinbergmedia/vst3_pluginterfaces/blob/m...

  # pluginterfaces should actually be a header-only library,
  # but it has some sources as well which need compilation.
Should theoretically be fixable right, so that it's purely the interfaces and doesn't need compilation? Why on earth did they do it like this?...

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

#23

Post by jcelerier »

gavinray wrote: post #22
jcelerier wrote: post #20

Earlier quoted context omitted.

I had looked into it ! but it seemed that making a DPF plug-in involved a lot of boilerplate, while I really wanted to do something where I can just include a couple headers and get going, without any particular compilation hassle (the whole library is header-only as it is pretty much entirely templates).

This is the absolute worst part of VST3. These 2 soul-crushing lines in the build file: https://github.com/steinbergmedia/vst3_pluginterfaces/blob/m... # pluginterfaces should actually be a header-only library, # but it has some sources as well which need compilation. Should theoretically be fixable right, so that it's purely the interfaces and doesn't need compilation? Why on earth did they do it like this?...

Yeah, until now I had resigned myself to linking against stmg_common in cmake. But maybe they can be split out to simplify that whole... Thing. I almost have it working, will push tomorrow after some sleep and then will add vcpkg as you showed :)

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

#24

Post by gavinray »

jcelerier wrote: post #23
gavinray wrote: post #22

Earlier quoted context omitted.

This is the absolute worst part of VST3. These 2 soul-crushing lines in the build file: https://github.com/steinbergmedia/vst3_pluginterfaces/blob/m... # pluginterfaces should actually be a header-only library, # but it has some sources as well which need compilation. Should theoretically be fixable right, so that it's purely the interfaces and doesn't need compilation? Why on earth did they do it like this?...

Yeah, until now I had resigned myself to linking against stmg_common in cmake. But maybe they can be split out to simplify that whole... Thing. I almost have it working, will push tomorrow after some sleep and then will add vcpkg as you showed :)

  > "I almost have it working, will push tomorrow after some sleep and then will add vcpkg as you showed :)"
Bless, the hero we needed but didn't deserve

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

#25

Post by loxias »

I just need to say:

I've spent some (the happiest part!) of my career (and ~2/3rd of my life, hobby wise) involved with sound/music technology, designing and writing audio (and some video) plugins (VST, AU, PD, and others), audio middle-ware, plugin host frameworks, low level DSP algorithms optimized for performance, authoring music/sound protocols (MIDI-over-BLE, and tons of unfinished network sync things...), translation layers for seamless porting of effects between APIs (ie: auto-generation of an iOS app, or embedded microcontroller code, from VST source code), algorithms/processes for "JITish" C/ASM code generation from a concise higher level mathematical definitions (think: something you'd type in a CAS), so you can edit the math at runtime, and see the result within seconds.

8 years ago I made a PoC of something similar to this, using dark C++ magic (policy based design, lots of TMP) to enable compile-time optimization of filter chains, where each filter is encapsulated at a source level then connected in a dataflow graph, to produce an optimized binary of the whole chain, suitable for running as an application or on bare metal. Apparently, much of what I was going for eons ago (with c++11) is possible now with c++20!

I've just begun to skim the code, with an arrogant "This is in my domain of expertise!" hat on. So far, I really, really like what I see, an uncommon experience when I look at Other People's Audio Code. All sorts of little clues that point towards "good code smell". ("Oh good, they used library..", "Hah! Correct usage of memory fences!", &c)

I tip my hat to you, author! I am embarrassed I hadn't heard of this project before!

As soon as I can afford to focus on anything non-paying, I look forward to contributing, competing, or both, with this project and author. :)

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

#26

Post by spacechild1 »

gavinray wrote: post #22
jcelerier wrote: post #20

Earlier quoted context omitted.

I had looked into it ! but it seemed that making a DPF plug-in involved a lot of boilerplate, while I really wanted to do something where I can just include a couple headers and get going, without any particular compilation hassle (the whole library is header-only as it is pretty much entirely templates).

This is the absolute worst part of VST3. These 2 soul-crushing lines in the build file: https://github.com/steinbergmedia/vst3_pluginterfaces/blob/m... # pluginterfaces should actually be a header-only library, # but it has some sources as well which need compilation. Should theoretically be fixable right, so that it's purely the interfaces and doesn't need compilation? Why on earth did they do it like this?...

Actually, you can write VST3 plugins/hosts using only the header files in pluginterfaces. (I needed to do this because the source files didn't even compile with MinGW. Maybe they have fixed this.) I don't use a single VST3 source file in my “vstplugin“ project: https://git.iem.at/pd/vstplugin

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

#27

Post by udbhavs »

loxias wrote: post #25

I just need to say: I've spent some (the happiest part!) of my career (and ~2/3rd of my life , hobby wise) involved with sound/music technology, designing and writing audio (and some video) plugins (VST, AU, PD, and others), audio middle-ware, plugin host frameworks, low level DSP algorithms optimized for performance, authoring music/sound protocols (MIDI-over-BLE, and tons of unfinished network sync things...), tran…

How would you recommend someone wanting to get into creating audio plugins (with very basic c++ and close to no experience in DSP) start? Also another thing I was wondering, does the math used in audio processing also come in useful for other broader applications like video?

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

#28

Post by fit2rule »

udbhavs wrote: post #27
loxias wrote: post #25

I just need to say: I've spent some (the happiest part!) of my career (and ~2/3rd of my life , hobby wise) involved with sound/music technology, designing and writing audio (and some video) plugins (VST, AU, PD, and others), audio middle-ware, plugin host frameworks, low level DSP algorithms optimized for performance, authoring music/sound protocols (MIDI-over-BLE, and tons of unfinished network sync things...), tran…

How would you recommend someone wanting to get into creating audio plugins (with very basic c++ and close to no experience in DSP) start? Also another thing I was wondering, does the math used in audio processing also come in useful for other broader applications like video?

Learn JUCE, watch some tutorials...

http://juce.org

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

#29

Post by loxias »

udbhavs wrote: post #27
loxias wrote: post #25

I just need to say: I've spent some (the happiest part!) of my career (and ~2/3rd of my life , hobby wise) involved with sound/music technology, designing and writing audio (and some video) plugins (VST, AU, PD, and others), audio middle-ware, plugin host frameworks, low level DSP algorithms optimized for performance, authoring music/sound protocols (MIDI-over-BLE, and tons of unfinished network sync things...), tran…

How would you recommend someone wanting to get into creating audio plugins (with very basic c++ and close to no experience in DSP) start? Also another thing I was wondering, does the math used in audio processing also come in useful for other broader applications like video?

> Also another thing I was wondering, does the math used in audio processing also come in useful for other broader applications like video?

Dear lord yes. YES. They're all signals (audio, images, video, radio waves, EEG readings, &c). Just in different dimensions and timebases. The math used to tease meaning from the signals is pretty universal.

Understanding fundamentals like convolutions, filters, frequency domain, bandwidth, sampling limits, &c are just as critical if you want to do video processing as audio. A Wiener Filter will clean up audio, as well as an image. To a very crude approximation, the math that lets us compress audio to MP3s is the same that lets us compress images to JPEGs.

That first question though, is hard. I've been doing it for too long to have any useful advice.. (sorry) I would say, the best way to get into it is to... well... just start.

Don't worry about the programming language, try things out in a high level tool, like MATLAB. With a foundation of simple diffeq and some stats, you'll be able to do stuff :)

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

#30

Post by udbhavs »

loxias wrote: post #29
udbhavs wrote: post #27

Earlier quoted context omitted.

How would you recommend someone wanting to get into creating audio plugins (with very basic c++ and close to no experience in DSP) start? Also another thing I was wondering, does the math used in audio processing also come in useful for other broader applications like video?

> Also another thing I was wondering, does the math used in audio processing also come in useful for other broader applications like video? Dear lord yes. YES. They're all signals (audio, images, video, radio waves, EEG readings, &c). Just in different dimensions and timebases. The math used to tease meaning from the signals is pretty universal. Understanding fundamentals like convolutions, filters, frequency domain,…

Thanks, usually questions on the internet about learning VST programming are in the context of producers wanting finer control over their sound so the answer is always "it's not worth it, just use Max/PD/Reaktor". But as a CS student who's into making music I was curious about how these tools are made and also how much the theory overlaps with other fields (which by your answer it does to a large extent). So its exciting to know the knowledge will come in handy in other areas and that its not a futile time sink :)
Post reply on HN