I was admonished (in not a nice way—not terribly rude, but quite to the point that I don’t know what I’m doing) by an anonymous visitor, who concluded that I don’t know much about C++ and maybe should have written it in a different language (why, when the purpose is to give people C++ code?). I would reply to him if he had left a real email address, but maybe I should make a few things clear to all.
I supply bare bones code. I try to leave out anything not necessary, and avoid even fairly obvious optimizations (and some less obvious that would make the code more difficult to understand. For instance, the wavetables could be one sample larger and let you avoid testing for wrap-around and the resulting branch). See About source code examples.
There is a common misconception that if your class is suitable for subclassing, then the destructor must be declared virtual. This is not true. If it were, the C++ architects would have simply built it in.
So, to some (including the anonymous commenter), it may seem confusing that I don’t declare destructors as virtual, which they might conclude to imply no subclassing, while declaring variables as protected (not private), implying support for subclassing. There is a method to this apparent madness: First, I don’t expect that the object will be subclassed by you, and I want to keep it efficient. So, I don’t declare destructors virtual, which would create some overhead we don’t need. However, if you do choose to subclass, then it’s important that you have access to certain variables, hence the protected declarations where appropriate.
However, that fact is that base class destructors need not be virtual when subclassed—that’s a requirement only if you want to delete them via the base class. By not declaring them virtual, we get the lack of vtable in the typically case (of no subclasses), while still allowing subclassing.
Also, I don’t mess with namespaces, and avoid templates even though they would be useful—again, trying to focus on the code that implements the DSP algorithm. I try to fit as much of the pertinent code on the screen for you as possible, so while I like comments in my code, I keep them brief.
And I don’t go through and declare every non-changing variable as const. This is not open source code. I’m not trying to protect you or some group you are working on code with from yourselves. I’m giving you seeds, not a framework, and it’s not in a Git repository. If I keep it simple enough, I figure you’ll be able to pull the bits out that matter for you into your own code. I don’t have time for both open source and tutorials—you can find a ton of open source oscillators, filters, and modulators on the internet, and I think you’ll find that the authors do not teach you how and why the code works. The latter is few and far between, and that’s why I’m here.
I’m open to suggestions, but realize that I do think about my choices, even if it’s not apparent. So, please, let’s make it a discussion. And the anonymous fellow is invited to point us to his contributions to the public. 😉
I’ve recently found this excellent blog since I’ve come interesting in dsp. I really appreciate the fact that the primary goal of your post are to explain in detail the theory and the fact that you even share “demo” algorithms is really great, you even go further writing in C++ and that a certain plus for me. I understand that this is not a framework and for the primary reason of the blog itself it shouldn’t be. So I’m with you! Thank’s for shareing your knowledge!
Haters gonna hate. Your code is great. Keep it simple. To the point. No need for complex C++, let me the implementor worry about that in the larger system.
I think your algorithm and details are great.
I work for one year on dsp in my spare time, and I think the information you gave are great and simple.
Thanks a lot.
Don’t let the “anonymous C++ expert” change what you’re doing here. I think I’m correct in assuming you’re providing source here to illustrate a point, something your code has done very well for me. It’s succinct, clear, and easy to pull into whatever I’m working on. Thanks, by the way, for the articles. They’re great.
I randomly stumbled across this discussion by way of your awesome dithering video. I just wanted to point out that there’s a bit of a disconnect between your arguments on the vtable and const-correct code.
First of all, I understand that the code was meant to demonstrate a point, and not an open-source. But any code you paste on the web is likely to end up in other people’s production code by way of lazy copy/pasters (believe me, I’ve seen it happen plenty of times with code that I posted).
That said, I also understand why you intentionally left off the virtual dtor in order to avoid the overhead of vtables. That’s perfectly fine, but then you state “I don’t go through and declare every non-changing variable as const”, which strikes me as a bit contrary. Modern compilers can yield large significant performance gains with const-correct code, at any rate much more than the addition of a vtable (which actually is alos optimized away if not subclassed, so ‘virtual’ iteself does very little harm).
For the purpose of example code intended to demonstrate a DSP algorithm, I can see why you may not want to “pollute” it with being const-correct, however I just wanted to comment on the performance consequences of const-correctness vs. vtables, which I felt was not accurately represented. Anyways great job on the code and videos here, keep up the good work!
Hi Nik. Good points, thanks for sharing, and maybe “pollute” is a strong word, but mainly I didn’t want the code to be wordy. As far as efficiency, I doubt that even much open-source code is optimized as much as possible—and the code I posted is pretty efficient. I’m not sure if you’ll see any improvement by adding const where applicable, and it would be interesting to see, but certainly it would pale in comparison with simply changing the update routine to an inline. I might publish a fully optimized version when I get around to adding a high-quality hard sync feature. For the code in the wavetable article series, the main thing was in illustrating the technique. As a bonus, I managed to make it pretty efficient without obscuring the code. At the time, I didn’t expect that inlining the update routine would be that much of an improvement, since I thought that the body of the function would eat more cycles than it does, on average, so I left it non-inlined as an example of trade-offs, but I definitely recommend inlining it if you’re looking for improvement. Beyond that, you won’t see much, I think. Of yeah, and you can make the wave table one sample longer (duplicate the first sample), and save a branch decision in the linear interpolation. I left that out for clarity.
Nigel
Hi Nigel,
As it is not your responsibility to write anyone’s code for them, I don’t see why anyone should complain. It is up to the person coding to make their code work efficiently.
If people copy/paste code from any website without understanding how to make it work in their project, then they have only themselves to blame.
These posts are, from my point of view, about how DSP works, not how to efficiently code in c++.
I appreciate all that you have put into this site; I have learned much from you.
Thank you. 🙂