Function alternatives and useful snippets of code

gioGramegna · April 15, 2020, 10:35am

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: https://forum.cockos.com/showthread.php?t=39781

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.

stoermelder · April 15, 2020, 11:02am

There is a fantastic guide for writing efficient plugins from @Squinky:

github.com

squinkylabs/SquinkyVCV/blob/master/docs/efficient-plugins.md

# 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:

This file has been truncated. show original

Squinky · April 15, 2020, 2:42pm

Thanks for the shout-out!

Squinky · April 15, 2020, 2:56pm

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.

carbon14 · April 15, 2020, 6:42pm

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.

carbon14 · April 17, 2020, 3:39pm

It’s not finished, but it’s more than half done:

Should be finished within the week.

carbon14 · April 20, 2020, 3:25pm

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.

gioGramegna · April 20, 2020, 3:30pm

Nice thanks.

synthi · April 20, 2020, 8:41pm

WOW ! SUPER! did you do also a speed comparison against sine LUTs ? (Various dimensions) + Harmonic distortions differentials ?

BRAVO !

Squinky · April 21, 2020, 1:07am

I’ve been using a linear interpolating LUT for… decades? But these approximations are pretty cool - I’d consider using them.

synthi · April 21, 2020, 7:51am

hehe Hal Chamberlin inheritance !

computerscare · April 21, 2020, 2:30pm

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π

${\Large \mathrm{sin} x = \mathrm{sin} (x - \frac{2n}{\pi})}$

Shouldn’t the formula be:

\sin x= \sin(x - 2n\pi) ?

Squinky · April 21, 2020, 3:18pm

Also only require math that we learning when we were 10 years old.

carbon14 · April 21, 2020, 4:29pm

Thank you. Corrected.