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
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.
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.
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!
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.
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.
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.
