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

31–36 of 36 posts

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

#31

Post by gavinray »

spacechild1 wrote: post #26
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?...

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

This is very useful to know -- TIL, thank you!!

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

#32

Post by gavinray »

udbhavs wrote: post #30
loxias wrote: post #29

Earlier quoted context omitted.

> 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 exci…

There is a massive online community (~10,000 people) of audio devs that will help you here:

https://theaudioprogrammer.com/discord/

There are some devs from some well-known companies, as well as maintainers of a few popular frameworks there.

They're (probably) going to tell you to use JUCE, use "Projucer" as a build tool, and C++ as a language. That's what most people do. I don't particularly love C++, and I prefer the CMake build, instead of their custom build tool, but potato-puhtahto.

There's also a Rust Audio development community:

https://github.com/RustAudio

https://discord.gg/b3hjnGw

And it may be a bit niche, but there is an (in my opinion) fantastic framework for writing audio plugins in D:

https://github.com/AuburnSounds/Dplug

It uses Physically-Based Rendering for the UI (PBR), which is generally used for 3D game stuff I think? It's a neat approach and the UI's it produces can look very realistic -- only framework that does this AFAIK.

The author Guillaume is a nice person and will answer questions in the #audio-dev channel of the D-lang Discord that is linked in the Dplug repo.

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

#33

Post by pininja »

jcelerier wrote: post #3
pininja wrote: post #2

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?

If you wrote a software that worked with soundflower it means that at some point you used to call either the CoreAudio API directly or any abstraction on top of it (RtAudio, PortAudio, ...). Thus harder to port to another OS :-) Here the idea is to write the algorithms in a way that is more future-proof, by not having them to depend on any run-time API, just a generic specification (given as a set of C++20 concepts).…

I appreciate your passion for this work! Ossia looks cool and I’d like to try it out sometime. The idea that this can be used for Max or as I’ve seen mentioned on other threads, video, is pretty interesting. Live performances are incredibly impressive fusions of multi-media and code.

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

#34

Post by p0nce »

gavinray wrote: post #32
udbhavs wrote: post #30

Earlier quoted context omitted.

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 exci…

There is a massive online community (~10,000 people) of audio devs that will help you here: https://theaudioprogrammer.com/discord/ There are some devs from some well-known companies, as well as maintainers of a few popular frameworks there. They're (probably) going to tell you to use JUCE, use "Projucer" as a build tool, and C++ as a language. That's what most people do. I don't particularly love C++, and I prefer t…

We welcome people that want to make a plugin business foremost (or already are in the market). https://dplug.org/

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

#35

Post by sletz1 »

jcelerier wrote: post #3
pininja wrote: post #2

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?

If you wrote a software that worked with soundflower it means that at some point you used to call either the CoreAudio API directly or any abstraction on top of it (RtAudio, PortAudio, ...). Thus harder to port to another OS :-) Here the idea is to write the algorithms in a way that is more future-proof, by not having them to depend on any run-time API, just a generic specification (given as a set of C++20 concepts).…

@jcelerier: would it make sense to have new backend in Faust the generate this kind of C++ code?

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

#36

Post by jcelerier »

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…

Had forgot to answer... thanks for your kind remarks :)

> I look forward to contributing, competing, or both, with this project and author. :)

yes ! please do :)

Post reply on HN