Airwindows - A Fresh Approach: Looking for some testers and feedback

Hi Folks

Many of you know the air windows ( plugins, a set of really interesting and distinct MIT-licensed FX plugins. In the Surge team we’ve been working with Chris (the airwindows author) on a variety of things over the years, and Surge includes many of these plugins. In rack, there was a set of rack 1.0 plugins which included about 14 of his fx, but air windows has never comprehensively made it to rack.

But that’s changed now! I’ve been working with Chris and several other members of the surge team to make a single module which contains all 328 FX in a single rack multi-effect module. To do this rationally you have to automate everything, and we’ve done that. And we are now ready for some patient testers.

As a reminder: patient tester means (1) you don’t mind downloading binaries from outside the library, (2) you are willing to give clear feedback on a bug either here on on GitHub, and (3) you realize that early stage software can change, so if you patch your chart topping track with one of these fx, it may not render the same (or at all) in the future. You know the drill.

But with that caveat: if you are interested in trying out where we are then

download there. (These modules will probably move from baconpaul GitHub eventually but for now they are there).

It’s really easy to use. Click on the name of the effect and a menu pops up that lets you choose any of the other 327. The front panel reconfigures appropriately. Each param has a knob, a CV and an attenuverter. The manual links to the list of what all the FX do.

For some fun: try using galactic as a super spicy reverb, or some of the amp models or Z Lowpass filters for some drive. But also just you know - explore this massive collection.

We have set it up so we can track Chris automatically as he adds new FX, but the one above is as of his GitHub repo from last night.

Anyway let us know what you think! and have fun!

(Oh and the todo list includes a few things around a UI review, a light mode, etc… but we think the DSP is complete)


I will give it a try and send you some feedbacks… regards…

1 Like

Yessss… Airwindows Rocks!!!

1 Like

Awesome, I love the lo-fi effects.

1 Like

Holy moly that must have been a fair bit of work!

I can’t wait to have all these, there are some real gems like the ones you mention.


This is astonishing work and incredibly welcome news. Amazing!

It actually wasn’t. It was more a judicious application of perl combined with the fact that Chris writes his plugins in an amazingly regular fashion. There is exactly zero per-effect manual work we have to do; it’s all parsing the documentation and vst source.


Hell yeah! And the Amp simulations too… That’s crazy! I love it. I’ll try to be a patient tester!

Oh and chris has given his blessing for this to be in the library with the air windows brand, so our intent here is to library-ize this after a testing period, just like we did with surge.

I just pushed a dark/light mode so new nightly in 20 minutes or so.

And I’m considering making a polyphonic option. The plugins aren’t quite CPU efficient enough for that in some cases but those filters…

anyway all ears for ideas bugs and so on.


I only very briefly tested a bunch of different ones and didn’t look up any of the documentation…


I see some of the modes do not require an input (such as DarkNoise), or perhaps the input should specifically be a gate or trigger in some cases rather than a generic signal?

Might be nice if there were some way to distinguish this visually

Also with the DarkNoise I saw that the Freq param knob is inverse to typical frequency parameters, might be nice if this could be reversed? (Obviously yes you can use the CV scale knob to do this, so not necessarily something that needs to be changed).

1 Like

And the great thing is, I do that regularity very much on purpose, specifically so greater programmers are able to leverage my stuff effectively. And with Paul, that’s astonishingly useful. I spent some time re-hacking Airwindopedia.txt specifically because Paul was able to reach into it and build menus out of how I’d made simple lists of the handiest plugins, by general type. So the total library and key things about the organization are purely down to me maintaining them: there doesn’t need to be a bank of skilled programmers keeping up, I just feed stuff into the machine.

And that means that once I have my feet under me again, this Rack mega-plugin will continue to grow on typically a weekly basis, and get everything new that comes out on my end… without me doing more than the eight platforms I directly target. :slight_smile:


Maybe add an option to disable dithering?

Good luck, Dan! Understand that it’s a heck of a deep rabbit hole to fall into. It’s a couple decades of work, all in a single module, and there’s never been that much documentation (airwindopedia.txt is the best I’ve got and there’s a fellow on Facebook who’s re-organized that information the way he likes it). So all the plugins are going to be what they are: when I have to do major library overhauls, it’s months of work, and there are definitely a few hidden bugs in there. I remember there was a time when I went in and removed every rand() call because it caused problems on Linux, replacing them with the value from my internal dither routine, and had to fix a couple things in the process.

I’ll ask this of the community: if there’s an issue with the port, or graphics, or something like that, by all means ask Paul about it. If the concern is ‘make this control work differently’ or ‘make this sound different’, you should go to the source and find my posts on various audio/music forums where I announce new plugins coming out, and join in there. Because to change things like that means changing all eight versions, in four codebases (retro and signed Mac get their own codebases), not just changing the one for VCV Rack :slight_smile:


I was about to say the exact same. This module has exactly chris dsp and no different. No new params or options. If we break that rule the project is infeasible. Zero touch automation or it fails.

That said detecting no inputs and recoloring the input section is a good idea if dark noise and voice of the starship and so on actually advertise zero inputs as opposed to just ignoring them


@jinx6568 : Chris, I just wanted to say thank you for the ability, creativity, years and years of work, and sheer expansive vision that underlies these wonderful algorithms. I am extremely happy that thanks to you, @baconpaul and the Surge team these will finally land in Rack. It’s an incredible collection and Rack is the perfect place for it.

@baconpaul, poly would be FANTASTIC for these (and as you point out it needs to be everywhere or nowhere due to the project architecture). If there’s real CPU concern in some cases, maybe enable poly on the right-click menu (under a warning) so that users buy in to knowing that TMMV depending on the algorithm chosen?


I was kind-of taking your comment of (and Chris’ backing of that comment, hi Chris :wave: great work on AW)

to mean that if the Dark Noise mode freq param is inverted, then all freq params would be inverted.

So rather than adding or changing the params specifically for Dark Noise, there could be a generic interface that would rescale params between AirWindows and VCV, sort of similar how Faust code needs to be rescaled for VCV in the prototype module because Faust uses signals of -1 to +1, probably its more complicated than that, but something to think about?

Yeah poly opt in of course is what I would do just like surge fx - and I guess if you opt in and burn too much cpu we can just apply the doctor joke! I’ll add it to my list


Oh no it’s not regular like that. It is regular like “every single param works the same way from an api perspective even the ones which are backwards and changing that is under the api”

The rack module is (kinda) a vst host (kinda but not really) in that I use Perl to munge the vst code and make those new classes adapt to the rack api. So if dark noise vst has frequency backwards so will dark noise rack and the fix is in dark noise upstream

1 Like

@baconpaul : Nice!!! (Forgot that’s how you do it in Surge FX, sorry…)

I’m going to steal “apply the doctor joke”, by the way.

@dan.tilley : I should of course defer to the people, who, y’know, are doing all the work :slight_smile: but my impression is that params aren’t regular in that sense (it’s more that the plugins are architecturally regular) [EDIT: confirmed by @baconpaul] and that getting into exceptions may open a door that would make the project infeasible given the sheer size of Chris’s repo. One weird idea would be to add a global expander interface that just broadcasts the name of the currently selected algorithm to connected modules (maybe with some kind of handshake first). That way if altering parameter functionality, etc. on an algorithm-by-algorithm basis was REALLY important to someone they could easily code it up as middleware (i.e. a module that passes Freq through unless alg_name is “DarkNoise” in which case reverse it).

(This could probably be done parasitically as well but having expander support would be a lot cleaner).

Isn’t the problem with changing it upstream that things like “frequency backwards” are probably choices, not bugs, and in any case reversing it would either require DarkNoiseV2 or break everyone’s existing patches AND DAW saves?

That’s a pretty cool idea, if there was some defined message format to indicate the algo in use, and another module or plugin that understood it, that had controls able to rescale the params. (In fact might we be able to do at least part of this using Patchmaster?)

Then the community could create rescale configs, save them as presets and share them around

1 Like