So, what does it mean to make a "plugin", anyways?
> Are all these plugins based in C?
Kind of? Practically speaking, all roads eventually have some C code at some point in the chain. This actually isn't for performance reasons, but because it's the path of least resistance.
Audio Plugins, as a concept, revolve around a thing in computing called "dynamic loading":
https://en.wikipedia.org/wiki/Dynamic_loading
In a nutshell: having the ability to load pre-compiled code from a file while a program is running, and then calling functions found inside of that bit of code. Rendering audio to a buffer, changing a parameter. That blob of pre-compiled code is gonna have the function for that!
Audio Plugins are little more than dynamically loaded files that have agreed upon a set of functions to use (a specification/protocol).
Dynamic loading (specifically libdl) is a feature that exists in C. dlsym, the function in charge of actually finding the name of the function, looks for symbols which correspond to the names of C functions. This is why plugin formats eventually boil down to C. It's just the path of least resistance. Even C++ plugins usually have a bit of C wrapper code at the end of it because C++ compilers mangle namespaces a bit during compilation.
> I was wondering, what are the best projects to just git clone and modify a bit to learn from?
I learned the most about the concept of audio plugins studying the original LADSPA SDK. As far as plugin formats go, it's the smallest and simplest. It's very easy to get to the bottom of how it works. Most modern formats like VST, LV2, AU, are enormously complex in comparison. The SDK even comes with sample code for a plugin loader, which I highly recommend glancing at. You can actually *see* the libdl calls like dlopen, dlsym, etc. Seeing that made most of the mystery go away for me:
http://www.ladspa.org/ladspa_sdk/download.html
https://github.com/adsr/ladspa-sdk/blob ... src/load.c
> Or is there anything that's worthwhile in Python?
Technically, I think you probably could write an audio plugin with Python. You'd just need the end point to be wrapped around a C function, and there'd need to be away to instantiate an instance of Python inside of the plugin. I would never discourage someone from doing it in the name of science and exploration, but my guess is that it would probably be very impractical.
As mentioned already, yeah, Python is usually not a good choice for real-time audio, specifically. With languages like Python, it's some kind of overhead it brings. Most of the time, this comes down to how memory is managed. Making memory allocation calls on the audio render thread is indeterminate behavior that can vary in time in ways that are hard to predict. This is *not* something you want when you have a buffer of audio that needs to be rendered in a certain amount of time or less, otherwise it will "drag" and cause an audible glitch. Languages like Python use Garbage Collection for memory management, which usually isn't suitable for real-time computing. It's not just a Python thing either. Most modern programming languages are implemented in a way that makes it unsuitable for the niche of real-time computing. Which is why audio programmers tend to gravitate to only a small handful of languages.
This classic "Time Waits for Nothing" blog post by Ross Bencina goes into more detail about this:
http://www.rossbencina.com/code/real-ti ... or-nothing