New sample VCO code for three VCOs, and detailed docs on how and why they work.

We have created a new GitHub repo that contains a very simple polyphonic VCO (VCO1), and then an improved but still very simple VCO (VCO2), and lastly a highly optimized version.

We wanted to show that it is really easy to make a VCO that uses very little CPU, and generates very few digital “nasties”.

The intended audience it mainly developers, but most of the information is general and only mildly technical, so anyone interesting in how VCOs work and what can go wrong should find something worthwhile in here.

We hope that the information will enable both developers and users to make informed decisions when the create or use or using VCV modules.

The code is written very simply and clearly (hopefully) with lots of comments explaining many of the steps in writing your own plugin. It’s very much like the old “Tutorial” plugin, so handy for people who don’t want to use the python project creator.

Then there is a large amount of documentation on how to test a VCO, why the Demo VCO1 is so terrible, steps taken to make VCO2 and 3 better than VCO1 and then testing and analysis of all the VCOs

Here’s the link: https://github.com/squinkylabs/Demo 45

24 Likes

It’s great, would have definitely saved me some time when starting out!

Thanks!

Thanks !

Just sent a pull request for some suggested text changes for docs.

Is it worth adding a glossary of terms to the docs? Happy to do that if you want.

I merged in the full pull request. Everything looked like a fix for something completely wrong, or just an improvement in wording. Very nice, and much appreciated.

Tried to PM, but I’ve got the forum app in some odd state. In any case, glossary sounds like a great idea. It should probably be another child page? If you want to send a draft or put up a full pull request, either would be much appreciated.

btw, your skills with git and writing are impressive. I guess you are software dev who is good at writing?

This document is a nice read, and a good template as well. I have left a couple of minor comments on github.

Are you planning to extend this document? One area that is not often covered is unit testing dsp code. I actually learnt a lot from reading your unit tests. The internet has a lot of documentation on writing dsp, but I found very little about testing.

1 Like

Thanks. Yes there will probably be more follow up, but I’m not sure unit testing will be it. One problem, as you are well aware, is that the Squinky Labs code is… not very concise? there are so many files, and so many classes in there that I don’t know how well it would translate. That’s why we made an entirely new repo just for this VCO exercise.

It’s difficult to convince people they should write unit tests. I have seen several VCV plugin repos that do have some test coverage. I’m quite proud that 2/3 of our source code is unit tests, and I really don’t understand how people can write high quailty DSP without doing that. But they do!

1 Like

Thanks so much. Will get these taken care of.

1 Like

We made a third VCO today - using SIMD for better polyphonic performance. Will try to get that posted soon.

6 Likes

I’ve had to do my fair share of documentation in a previous life. :slight_smile:

1 Like

The problem with unit testing is that a plugin requires so much infrastructure just to be loaded.

In a perfect world, a plugin would be a non-interactive core with no dependencies on the rack infrastructure, which you could write a test fixture around, and then a separate ‘link up core to rack’ library. Then you could write unit tests of your inner code, without the entire Rack app infrastructure.

It’s a challenge not limited to Rack. In the web development world it’s difficult to isolate components to where you can do non-interactive tests with components, particularly client-side code, because the test is ‘load the url in the browser and see if the right things are displayed.’ Hard to automate that, which is why the companies that provide test software that can do that make the big bucks.

My company has a very simple setup to handle that for server-side testing: The backend (a CGI program run by Apache to generate content dynamically) is instrumented to take all the information in a web request and write it to a file.

So testing the server CGI can be non-interactive shell scripts, that ‘replay’ a request by passing a captured request file on the command line.

Something similar could be implemented to capture the event stream from the GUI for a plugin, and replay it, but it’s a non-trivial effort to make that happen – way harder than capturing the Apache CGI environment and post data and dump it to a file.

True. Squinky Labs plugins punt on this issue. We have a clear line between “VCV/Plugin” code that we can’t unit test, and our own code that is isolated from that and which is easily unit testable. It’s a compromise, but it works ok for us. Could be better, but way better than doing nothing.

Just now we added a third VCO to the project, and updated the thread title and first message.

1 Like

We have a clear line between “VCV/Plugin” code that we can’t unit test, and our own code that is isolated from that and which is easily unit testable.

As it should be. Also because you can port a ‘pure’ core to another environment (i.e. VST, IOS, whatever). Then you lash up a user interface that plugs into all the inputs and does it’s thing.

1 Like

Bless 'ya Bruce for being committed to performance and sound quality, and for showing the way. Really appreciated!!

A while back I set out to test the sound quality of various VCO’s, using a simple test setup, a spectrum analyzer and my good ears. Once you hear and see digital aliasing and other artifacts you can’t unhear it. It makes a drastic, audible difference that will just accumullate throughout a patch. I was quite surprised actually of the difference in sound quality between the VCO’s.

1 Like

Thanks for the shout out!

1 Like

I admire your will to help newcomers. This would have helped me so much when i started.