Umm … was wondering if anybody would be willing to beta test my plugin/modules before I submit them to the Library?
They’re nothing particularly radical (basically HetrickCV Waveshaper with some additional parameters and the option to compose waveforms by stacking expanders) and it’s a first iteration so I’d be more than happy just to know they don’t crash horribly on something other than my ancient x64 Macbook which is all I’ve been able to test on.
There are pre-built binaries in the Releases section for all the platforms I could think of, so with any luck you shouldn’t need to build it locally.
I found no problems of bug whatsoever on win10
I tested chains, both forward and backwards, they are a very nice touch on additive oscillators!
will you do a manual?
Thanks so much!! Really appreciated!
re. manual. There is a manual of sorts - it might be a bit minimal but wasn’t sure what else to put in it. I guess some examples might be useful…
just downloaded on mac x64. im no coder but I will test as best as I can. these are really interesting modules.
Awesome! Thank you … any feedback is much appreciated!
update: these modules are so fun. they pair insanely well with unstabile from vult.
here’s a lil patch with marbles driving, modulating envelopes, and parameters on your modules. I’m using two sets of sn-vcos with expanders, a sub sin wave, and a noise source for a subtractive kindof setup. valhalla supermassive vst is providing an odd kindof smeary delay.
Huh! That is interesting - I’d been wondering if it was possible to get a more percussive sound rather than the very conventional and keyboard-y sounds I’ve mostly been using.
Do these VCOs suppress high frequency aliasing? If so, by what method?
They don’t (at least not as yet) - in an earlier iteration I had a low-pass filter on the output but after looking at the FFT the high frequency component was so negligible I decided to leave it out for now and just let whatever aliasing there was fold back into the audible region (plus I figured an external LPF would be ultimately be more flexible).
My ears aren’t that good though - are you picking up artifacts?
No, my ears are old. But in general any VCO that implements some kind of “function” is going to generate aliasing, unless you do something fancy to get rid of it.
Here’s an article I wrote about how to see it: Demo/docs/aliasing2.md at main · squinkylabs/Demo · GitHub
fwiw, I think all of the “popular” VCOs implement some kind of alias reduction.
Here’s the output of sn-vco, showing a lot of aliasing:
I was very intrigued by the concepts behind the SN-VCO, but the very prevalent aliasing renders it unusable for me.
I imagine it would not be too hard to add oversampling to the code and mitigate the aliasing problem. I would probably revisit the module(s) if that were done.
@Squinky, I read your article way back when, when I started the development … but somewhere along the way I decided an external filter would be a better solution.
Interestingly it hasn’t been a problem for me, but that’s probably because I tend to use it in the middle of the range and the occasional excursions to the extremes are brief and sometimes I want it to sound a little weird.
Ok, I’ll put antialiasing back on the TODO list - it’s clearly better to do it internally.
You can’t filter it out after the fact.