Since the Reaper forum has one thread for JS programming i thought it would be a good idea to have one here for plugin development.
Starting here you can find some great pieces of code which you can adapt to vcv rack:
Also you can share:
code optimization techniques - what is faster?
any snippets of code - that may be useful to future coders.
"dsp explained" notes - how does a filter work? how to do convolution?
any interesting dsp related articles - books and lectures.
There is a fantastic guide for writing efficient plugins from
This file has been truncated.
# Efficient Plugins
## The challenge
When most computer software is slow, the user needs to wait longer for the software to respond. But with real time audio systems like VCV Rack, slowness manifests differently. Typically everything is fine until enough things occur to slow down the audio calculations and the buffers underflow. The results are usually a sudden onset of pops, clicks, or missing audio.
When writing plugins for a real-time audio system like VCV Rack (or VST, Audio Unit, etc.) there is the additional complexity that the “system” is a collections of software from different authors with differing strengths and weaknesses.
One plugin that is a CPU hog, or otherwise misbehaves, can make the system click and pop. For the user it is very difficult to tell which plugin is the culprit. For this reasons, it’s very important that any plugins distributed to end users be well-behaved, and that they document any known issues.
## VCV Rack 1.0
Rack 1.0 will be multi-threaded, which means that most users will see a 3X increase in available CPU. That will allow many of today’s inefficient plugins to work without immediately causing pops and clicks. But that doesn’t mean we will be able to get away with inefficient plugin code. VCV users want to use that extra CPU power to make bigger patches that are more reliable. They don’t want us devs to use it ourselves to run our inefficient code.
## What causes buffer underflows
At the hardware level, most audio interfaces operate on buffers of audio data. The audio software does its processing, and delivers a buffer of audio to the interface. If the last buffer is still playing when the new one is delivered underflow will be avoided. If for some reason VCV Rack is not able to deliver a buffer of audio before the previous one has played, an underflow occurs, and the audio interface can’t play anymore.
Buffer size is settable by the user, and typically ranges from 64 samples to 512.
VCV 0.6 has a single-threaded audio engine. If there aren’t a lot of other programs running and competing for cores, that means VCV will have an entire CPU core to run audio processing.
There are three things that plugin software can do that will cause VCV to underflow:
Thanks for the shout-out!
There are two things I wish I could add to my (old) paper. First is the sin approximation that now comes with the sdk. The other is the SSE library built into the sdk which is especially useful for polyphonic modules. Unfortunately I not an expert in either area.
I was planning to write a paper explaining both the standard sin approximation, and the SSE version. I’ll move it up my list of priorities.
It’s not finished, but it’s more than half done:
Should be finished within the week.
Now completed. It covers:
the general idea of the algorithm
a step-by-step breakdown of the standard cephes implementation
a matching step-by-step breakdown of the SSE implementation
It’s intended for an audience that can already program in C.
WOW ! SUPER!
did you do also a speed comparison against sine LUTs ? (Various dimensions)
Harmonic distortions differentials ?
I’ve been using a linear interpolating LUT for… decades? But these approximations are pretty cool - I’d consider using them.
Hal Chamberlin inheritance !
Very informative paper David, thank you for putting this together!
In this section:
And because the sine curve is cyclical, anything to the right of 2π can be handled if we reduce x by modulo 2π
Shouldn’t the formula be:
\sin x= \sin(x - 2n\pi) ?
Also only require math that we learning when we were 10 years old.