Hi Jatin! Thanks for this update and my requested enhancement for Credit module.
I was a bit swamped with construction work at my house. Will let you know if more ideas pop into mind at a later point again.
Looking forward to checking out the new ChowDSP modules!
Hi All,
Just made some builds with the latest Rack SDK (2.beta.1 for anyone counting), which are now availble on GitHub for testing at this link. At this point, I would say the plugin is “feature complete” for version 2.0.0, so I’ll probably only be making bug-fix and documentation changes at this point before making an official release into the VCV library for Rackv2.
I added a “chorus” module based on a similar effect I helped implement in the Surge Synthesizer. I was hoping to add a spring reverb module as well, but I think that will have to wait a little bit while I figure out some more things on the DSP side.
Thanks, Jatin
Love me some spring reverb, hope it sees the light of day soon. Let us know if you need testing.
Everything works great so far here on my Mac. I love your modules and VSTs as well! Your plugins for DAWs have been especially nice on electric guitars, I imagine your spring reverb will be right at home there as well. Thanks for the modules! Cheers!
Thanks, glad you’re enjoying the plugins too! I’ve actually been in the process of learning guitar myself and building a little guitar-centerred plugin along the way, which is where the spring reverb development started. It’s still quite early in the development process, but all the code and such is on GitHub.
Very cool! Like a guitar amp sim? I wish I knew enough coding to know how to build stuff. If you need a tester and have a Mac build, just let me know. I also teach guitar online if there’s anything I can help you with in that area as well. In fact, one of my students who is just getting into recording uses your Centaur VST.
Edit: Oooh there ARE builds available. BYOD is awesome so far. It’s like a modular guitar amp!
Would love to have that guitar plugin as a module. Already love the klon one.
Glad you’re liking it! I’ve spent much of the past week trying to figure out some basic structural issues, so it’s still a ways away from being stable enough to use regularly, but I’ve had some fun playing around with it myself 
.
And yes, “nightly” builds for all the ChowDSP plugins are on our website.
The plugin is already a little bit modular internally, but I’m hoping to bring over some of the internal processors to VCV, starting with the spring reverb. Some of the processors would be a little bit redundant in VCV (like a mixer or stereo signal splitter), but the ones that are actually doing interesting guitar-related stuff could definitely be fun.
Yes please, do make the spring reverb and any other guitar related fxs for VCV, it might be even worth getting V2 for those!
I know WARP is supposed to be “wonky”. Do you know why there is what looks like really quiet white noise in the output when heat is in the middle?
I’d have to dig into the algorithm again (haven’t really looked at in in ~1 year), but I remember looking into it a little bit at the time. IIRC, the source of the noise comes from floating-point numerical imprecision, which then gets amplified in the feedback loop of the filter. I wonder if it might make a difference there using double instead of single-precision floats… maybe that could be a right-click menu option in the future
Interesting. Well, it looks like it’s low enough it would rarely be audible. I’ve run into that the with 50Hz high-pass on the output of my wave-shaper, but in that case it’s because it was a multi-pole filter at a low frequency.
In my case it was “easy” to switch to doubles, because all my filter primitives are templatized for float/double/float_4. fwiw I haven’t noticed that double takes noticeably more CPU that float. Of course four doubles take much more CPU that one float_4.
Hi VCV folks, been a while!
I’ve been excited to finally getting back to working on some VCV stuff this summer. I’ve started working on a new batch of “secret” modules, which probably won’t be in the VCV library for a while since they’re dependent on C++17. There’s a whole bunch of reasons behind all of this, so if you’re curious, definitely check out the README.
I figured I’d post about it here since I’m always open to anyone wanting to test out or contribute to these modules. In particular, I haven’t really figured out what I want to do for the graphic design of these modules… maybe I’ll stick with something similar to the original ChowDSP modules, or maybe I’ll do something different. I feel like I would prefer to have more of the design defined in code, since I feel like I used to spend a good bit of time fooling around in Inkscape, which I’m not particularly adept at.
By the way, calling them “secret” modules is mostly a joke… if they were actually secret, I wouldn’t be posting about them here 
.
The readme doesn’t mention why you need c++17. So I’ll guess: “it’s what we have been using other places, has some nice things, and now it would be a lot of work to remove it and go back to c++11.” Am I close?
Also, what does this mean? " * MetalFace: the most expensive guitar distortion in VCV Rack?". Do you mean expensive to develop or that it will be a paid VCV module at some point?
Yeah, I guess I didn’t explicitly say why the dependency is C++17. As a short answer, your guess is 100% correct.
Basically, there’s three libraries that I’m currently using (chowdsp_utils, chowdsp_wdf, and RTNeural). chowdsp_wdf and RTNeural are C++14-compatible, chowdsp_utils is C++17.
The main C++17-isms, that I’m using are if constexpr and template syntax helpers (i.e. std::is_same_v<T1, T2> rather than std::is_same<T1, T2>::value), so I could probably get down to C++14 without too much effort.
The reason why getting down to C++11 would be so difficult, is that there’s a bunch of places in my code where I do abstractions of sample-level processing which rely pretty heavily on variadic templates. For example:
template <typename... Types>
struct SampleProcessor
{
inline float processSample (float x) noexcept {
// iterate through `things` in some fancy way to do the actual DSP work.
// this is the part that almost always needs C++14. for example...
forEachInTuple (things, // I haven't found a C++11 forEachInTuple implementation that I like
[&](auto& thing, size_t index) // `auto` lambda arguments needs C++14
{
// do something fun in here...
});
}
std::tuple<Types...> things;
};
One example of this type of thing is the R-Type adaptors in the WDF library. I’ve spent a good bit of time fighting with these ideas in C++11, but all the solutions I’ve figured out would either sacrifice a good bit of performance, or require a lot more handwritten code, often in the most error-prone and performance-critical places.
Anyway, the idea for me right now is to just “have fun making modules”, which at the moment means using libraries in their current state. There’s other reasons why I may need to improve the libraries’ compatibility with older C++ versions, so if that happens then it would probably help out this project as well, but I’ll cross those bridges if and when I come to them.
Oh I guess that is misleading… I meant expensive as in “your CPU will need to spend a lot of cycles on it”. Although, I guess the hardware that module is modelling is also very expensive, so it could have meaning that way as well.
I’ve been messing with using neural networks to model guitar amplifiers (similar to the GuitarML project), so the idea was to experiment and see how large of a neural net I could put into a VCV module, before the CPU usage becomes impractical (partly as a test of the RTNeural library). Right now MetalFace uses an single-layer LSTM model with a “hidden size” of 28 “neurons”, but it’s only showing 6-7% in the Rack CPU meters on my older laptop, so I may need to train a larger network if I really want it to be the “most expensive guitar distortion in Rack” .
At the moment, the plan is for all these new modules to be free (free beer) and free (free speech), just like the “official” ChowDSP modules.
oh, cool! The guy in the office next to me used to work on amp sims. He would blast the same 2 second clip over and over all day every day. It eventually become “Eleven”, which is think is a pretty good amp modeler.
About 15% on my 2013 model Mac laptop… 
C++17 is not a problem for the library submissions (anymore). We updated the Rack toolchain to very recent version of the compilers when Rack 2.0 was released. As long as the compilers support the constructs you are good to use them.
Your plugin in its current state builds successfully for macOS and GNU/Linux platforms. There is a compile linker error on the Windows platform that I have submitted as an issue to your repo.
Long story short, feel free to submit your plugin to the library when it is done.