Hi to all!
Version 2.4.0 of Ad, my additive oscillator, is available in the VCV Rack Library. It has a new, much smaller front panel now, with space to display a spectrogram. There’s more info in detail on the new features in the manual.
Cheers! Matthias
Thank you! Looks and sounds intruiging. Looking forward to play with this…
I loved your module originally, the proportion looked perfect. The size of the module has been varying so much since its initial version, this has an impact on the distribution of my patches, in fact I supported the original version. The passion and work in your module is greatly appreciated but it is a topic. My respectful greeting
Oh no, I’m sorry @jerezsurfboards !
Does anyone here know whether a VCV Rack user can use old version of plugins?
Otherwise I can see if I can give you the source files, so you can compile them yourself using the SDK.
Thanks for your critique as well as your kind words. I’m actually curious what music you make with the module.
They can; but they need to delete the folder for that particular plugin in the plugins folder with Rack closed; put the older version .vcvplugin in the plugins folder (install it manually); and whenever an update pops they must ignore it… i.e click on individual updates instead of using “Update all”. Another option is to use both the old and new; but one of the two will need to have a different slug name. From jerezsurfboards message, I gather that would be the needed change (though, probably use the new slug name for the old version, lest patches using the new one break). Now… that would work only for whoever has that plugin locally i.e. distributing patches for people who have updated will still use the new version, not the old one. Your plugin mentions its GPL-3 (and that requires providing source), so that would make it easier for jerzsurfboards or someone else to “spin off” the old version under a different name and distribute that; though jerezsurfboards would need to update his distributed patches to use that “new” old version with the new slug name (probably also a different name… I don’t know “Ad legacy” or something).
Firstly, thank you very much for your modules. But I have a question. Is it normal that “van Ties Ad” module uses so much CPU?
Do not worry there are options. Im very visual and how I saying before, the version 2.2 of your plugin is for me so much clear, but is a taste thing. I will tried of make send some of my sound. Regards
Yes, I am in the first option mentioned using version 2.2 of Ad. Good idea to have the plugin option like Legacy.
Yea, I’m afraid it is, sorry. This is one of the things I want to work on next. Suggestions in this regard are welcome.
Cool module! I had a quick dig through the source… it’s very complex!! I appreciate how well commented your code is.
I am not sure where gains can be made easily, it’s computing a LOT of sines and cosines (quite unsurprisingly), and also quite a lot of logs and exps, all of which are expensive for CPU. So any reduction of these computation would pay off in CPU quite a bit.
You could consider maybe using a wavetable for the sines due to the large amount of trig computations going on.
If it is possible to run the Sieve function less often, perhaps only when the knob changes value, that could possibly save a little. Perhaps even put all the factors into a cache as you calculate them rather than recompute them all the time.
For any slower modulation parameters you can avoid re-computing them so often by updating those parameters less frequently (say 1:10 cycles or even less).
Here’s a link to the plugin source ( @Bloodbat ):
Also @matthiassars , you can add the source link to your plugin.json so it’s easier to find.
Thanks, @codyge !
I was thinking in along the lines of computing the amplitudes in a lower rate as well.
Regarding the sines: per sample 1 cosf and 2 sinf are computed (plus 1 sinf for the fundamental output). The other 126 sines are computed recursively from those. I tried using an approximation (Bhāskara I), but that didn’t work. I guess it isn’t precise enough for all those recursive steps.
I’ll include the link to the code in the next one. Thanks for pointing that out.
(Hi to you all from Superbooth, btw! 
)
Yes, the imprecision of sine approximations can really add up in certain cases. Using an approximation would save so much CPU, but if it’s not precise enough then it breaks the whole thing. I have a similar issue on my Ouros phase-injection module, where literally everything needs to be processed every cycle or it just doesn’t work right.
Additive synthesis is just expensive, and that’s why it’s a more modern thing compared to filtering (which is super cheap!).
Thanks, I might end up being the one who spins it up for those who want the old version… maybe 
You don’t need wave tables to make transcendentals faster… regular old, precalculated tables will do.
Depending on what the plugin is doing… it may benefit from parallelizing with SIMD.
Also, regarding performance coding, have a read of this good old writeup from Squinky:
Oh, wait, I tried an approximation for the sines and cosines again, and it works now. I guess I simply made a mistake the last time.
Regarding SIMD: as I undersand from Plugin API Guide - VCV Rack Manual , “accessing SIMD array elements with index notation a[i] frequently defeats the benefit of SIMD”. That might be a thingy in my case.
… but listening closely to isolated higher partials I do hear (and see in a spectrum analyzer) some impurities now. I guess that’s called character. 
Hi! I submitted a new version, which should be nicer to your CPU.
