when I used to make modules I found that a “best practice” was to have input and output level control and a vu meter of some sort on the output.
Probably will use the same technique to finish off the clap i prototyped last summer yeah
The plugins are all available from chris already as an au and vst2
Yeah, just would be super convenient to have them all in one plugin… and right now VST3 would be the one that I could use everywhere, including in the free Waves StudioRack plugin (which is super cool for mixing, since it can create parallel and frequency split chains in every way - but only takes VST3).
Thanks!
The mindmeld poly summing options in the AW right click menu are intended for this, similar to the old Rackwindows Console MM. As I understand you can take the poly outs from the mixer as I do with Mrg8 but use the MindMeld summing instead of the poly stereo summing.
Definitely YMMV on how noticeable the effect of the sin/asin summing is. I seem to notice something but it is so subtle that I can’t be sure. With the non-“Purest” console types you get additional color but iiuc that’s just post-processing the summed signal and could be done independently, with a typically summed signal. If you just want to test the summing changes, use the “Purest” versions.
I do wonder what effects you could get by processing the summed signal before inverting the transform with the Buss plugin. I imagine it would sound like a much milder version of the uLaw transform, since the transfer function is much less extreme.
I don’t have a way to make VST3 yet. I think it’s possible that by dual-licensing under MIT and GPL I can facililtate putting out VST3 as GPLed open source, without signing off on a license that has (at some times) taken away the right to VST2? I understand that’s not the case now, and I am legally grandfathered in as a VST2 creator, but abandoning the legacy support is not acceptable to me.
Also, the reason this plugin exists is that Paul doesn’t have to CODE all the little sub-plugins. Because the codebase is very consistent, Paul’s got elaborate scripts that read in all the plugins and implement the resulting Rack module, including adding new ones each week (in the dailies) without serious effort on his part. If there’s a comparable CLAP plugin it’ll be a machine working along similar lines.
I don’t have assurances from Steinberg (heck, they neither know or care I exist) that if I first learned how to make generic VST3s, and then spent weeks or months porting all the VST2s to VST3s and then spent additional time every week doing a VST3 for every relevant platform and architecture, they wouldn’t turn around and attack my ongoing support of VST2, which they want to suppress. So there’s a serious conflict of interest there, meaning it’d be better if someone either ported all the plugins, or automated such a port and took it on themselves. I’ll cooperate by keeping my codebase very automate-able: Airwindopedia is specifically designed to give support to such efforts, and you see it in the Rack plugin.
I do wonder what effects you could get by processing the summed signal before inverting the transform with the Buss plugin. I imagine it would sound like a much milder version of the uLaw transform, since the transfer function is much less extreme.
That’s easy, has long been an audio hack for people. If you put a typical digital EQ inside Console, you get an ‘expanded’ version out, which highlights things like boosts and cuts. If you put delays and reverbs in there (a favorite trick, and some of my plugins do this internally!) you get a deeper soundstage, along the lines of ‘saturating stuff tends to make it come forward in the sound picture, antisaturating makes it drop back’. And it is indeed much milder than the uLaw transform, and you can try it with the Purest versions, and when I use it inside plugins for this purpose I’m generally using original PurestGain, the minimal sin/asin version.
No worries. If it’s not inconvenient it would still be cool to have the all-in-one plugin as VST2, or have all FX in Surge and Surge FX, or both. But having them in Rack like that is really nice anyway, and I think I haven’t even tried all the ones that are included in Surge.
I don’t think it’s worth for you to learn VST3 or deal with steinberg at all, just thought it might be easy to push it out for baconpaul, maybe as part of the surge team releases.
Yeah finishing up the clap that does this (using the rack scripts) is on my list but my list is long.
a fun little fact: some hosts (looking at FLStudio…) did not even bother to implement generic UIs for VST3 plugins. everyone loves their custom UIs, maybe a bit too much…
Hmm… is Galactic2 in the Nightly Release (win) expected to sound this quiet in VCV?
(Sorry for the not too scientific question. It’s just my first impression.)
@jinx6568 Hi Chris, is there any chance you can show a “recommended” or “basic” setup using the Airwindows Console modules working the way they are designed to work?
Having the Airwindows effects available in this form is just so good, thank you for that.
Today when browsing the numerous cool effects in the VCV module, it hit me: having this available as a standalone VST would be awesome, too. Basically, the same stuff as the module, built as a VST - no CV inputs of course, but otherwise the same, i.e. Airwindows stuff categorized and switchable and searchable like this. This collection, as a multi-effect, loadable directly into a DAW (without always hosting it inside VCV) when all you need is some Airwindows goodness on a channel
Agreed! Ive noticed the VSTs use less cpu than the Airwindows plugin in Rack. So in a DAW, I would load an instance of Rack only to browse through the effects (because it is so much easier), and then copy the settings over to an Airwindows vst.
The rack version will use more cpu because of a substantially smaller block size since rack uses 1 sample processing and your daw is block based. If you can tolerate the uncompensated latency in rack you can increase the block size from 4 to a higher value and reclaim some cpu.
There are a few other buffer shuffles we need to do thst the vs doesn’t also which burn some cpu but the block size is the biggest difference between the daw.
I used the same technique to make a prototype of the clap adapter for airwin, but they’re projected into a single clap with 325 sub plugins. Also surge proper has a subset of the fx.
The same technique could make a single juce plugin quite easily. Just my list is long etc.
Thanks @baconpaul . Ive been wondering about that. I always try to be as conservative as possible when it comes to processing, so I always up the block size in Rack. I don’t notice a difference, maybe I just have really bad ears .
Not the audio block at the edge. Even if you set thst to 2048 rack processes internally a sample at a time. The airwindows right mouse lets you pick an internal block size.
But this will add latency since the module has to collect n samples before generating the first output. It also sets a sample size for all the cv controls which are snapped per block. For some things like big unmodulated washed out reverbs that’s ok. But for others like filters and compressors it isn’t
And vsts don’t do this, the daws topological sort the signal path and process it per block which is very efficient but which forbids the feedback techniques that make rack entertaining
That is exactly what I wanted to ask, thanks for clearing that up for me.
Thanks - and yeah, good point about Airwindows already being in Surge as well. As these are already available in a multi-effect plugin, even, in Surge XT Effects, perhaps having some of this ease-of-browsing / searching goodness available in that (instead of doing yet another packaging/version of Airwindows effects, in a new multi-effect VST) would probably make more sense