Rescale config is a clever idea
Mostly because it would be json that someone else could maintain if they wanted to join the project with chris and me and the crew 
Lemme ponder that some. Unlike surge where the fx and osc are template parameters here they are ifs so need to make it a bit efficient
Yes. I explicitly do v2 versions (etc etc) for that exact reason, so old saved projects etc. don’t break on people, and it’s led to many, many versions of some things. So basically if you like DarkNoise extra much, learn to use it the direction the controls go, because there was a reason. I’m wholly capable of picking which direction the brightening/darkening/etc goes, and adjusting the ballistics of the controls (for log taper or inverse log taper etc) and do that in great detail on all the plugins. So any choice of that nature is never just omission, it’s because when I made the plugin I wanted it that way for some reason.
Maybe I was just having a weird day that day 
Doing it as an integrated config would be slicker and not require users to do outside coding but doing it as an expander would be low-overhead and keep those concerns entirely outside of the project.
The expander approach would require as little as possible from the main project (just a one-time implementation of a protocol) so that if anyone wanted to take on the work of, say, conforming the amp sims, regularizing the filters, etc. they could do it entirely outside of the VST=>Rack pipeline with arbitrary complexity. (Allowing the same expander connection to change algorithms would be the only other feature I can think of. I’m imagining, say, an amp-focused expander that drives the amp sims–which already have consistent controls, of course–but exposes on-panel master volumes for them, different send/return chains, etc. All it would need from the main module is a way to get and ideally set the algo).
@jinx6568 : exactly! Let users write metaparameters if they want, how they want, but keep your original design ideas entirely intact (and by the way your attention to parameter scaling is one of the many things I greatly appreciate about AW; it’s so important)
Can’t you just put an inverter module in, though? I find it quietly horrifying that, after all this, Paul’s contemplating adding a whole layer of configurability to do things like reverse controls of particular plugins. I’ll defer to him on whether it’s worthwhile and whether it will bog down operation of the plugin, but man… I need to use that plugin too! I can’t make one of my own. And I had everything arranged the way I want it, so running every single possible parameter input everywhere in every AW instance through an extra routine just in case I wanted one of them to be rescaled or backwards? I would courteously suggest that maybe the port doesn’t need to have that when we are in a modular system and there’s modules to do these things for the situations where they need doing? Though again, this port is not mine to dictate how it can or can’t run, it’s a luxury that I greatly appreciate no matter what happens to it
yeah you are right chris. These modules are just-the-raw-dsp
if someone does want to write a re-mapping expander I can add a 1-screw-wide version of the module with no UI and people can expander onto it.
Also, remember the whole thing is stacks of open source projects. There’s NO end to the amount of fiddling one can do, but I like having the no-fuss complete library just exposed as is. Everyone has every opportunity to make curated and rescaled lists of plugins and combinations of plugins, Surge Synthesizer itself does this and I’m delighted. I would suggest that if it’s ‘rescale this one parameter in this plugin please’ you’re already in the place where maybe you’d like to start from a curated list, and go from there?
I know one of the Surge folks would really like more levels of submenus, and it’s the same deal: I understand, and when it’s up to me I have it in a different way for specific reasons. I’m hoping to be able to point people to this as a pretty direct extension of what I’ve already built. There’s usefulness in, if you’ve used one of the plugins, and then you see it in somebody’s Rack setup, recognizing the one you’ve used and knowing how it operates. Some of these have been around for a lot of years…
The opportunities are pretty endless, really
Just to be clear, the description of the Dark Noise Freq param being inverse, was not meant to be a criticism.
Its merely an observation when comparing it to typical VCV modules.
As a frequent VCV user and a never before today, Airwindows user, it took me by surprise. It also made me question if the CV input for the Freq param would respect the VCV V/Oct standard.
Again, its not meant as a criticism, but I would imagine that a layman user of VCV would have much more success using this module if there were a way to have the parameters behave in a way that is consistent with typical VCV modules.
Well said, and I totally agree! To be clear, I’m suggesting to not do a configurability layer for those reasons (and the ones you point to in your other post). The config idea was from @dan.tilley–I was proposing an expander protocol limited to getting and setting the current algorithm so that other devs could easily hack on whatever they wanted without requiring anything else from you/Paul/the team).
@baconpaul, a 1U expander that does internal parameter passing would probably be more elegant for this use case anyway–no need to string up extra wires. If you felt like writing that version I think it might get put to interesting use and shouldn’t be too distracting from the main event.
Super important!
That is a most fair observation for this particular library of stuff built into a plugin, the answer is ‘there is no way it can possibly behave consistently with existing VCV standards’ especially V/Oct, 'cos back when I did some of these I didn’t even have a modular synthesizer much less VCV Rack
So it’s a really good observation and could even be seen as a fault, but it’s one of the costs of getting into Airwindows. You kinda have to experiment and there are surprises and strangenesses, and you’ll have access to all the experiments because old stuff is NEVER refactored and replaced with newer stuff. If there were new things designed to honor 1V/Oct from the start, they would be added to the existing things rather than replacing them.
This is a perfectly valid criticism. What you get from the cost of dealing with this, is a situation where, if you DID take a liking to some obscure thing in there, your ‘secret weapon’, that thing gets maintained and included just as it is, in new formats, and is never taken away from you
Yeah
I also rather like the idea of using the tricks I made to have a separate ‘custom expander’ (or heck even ‘custom ui’) project which “someone else” does where you can use all the code here to remap params, draw fancy faceplates, etc…
that was partly the goal of the v1.0 air win to rack. they got through about 15 fx or so I think before they stalled since they had to do “something” per. This particular project is in some sense the exact opposite approach and so with things like parameters and UIs, you kinda get what you get, and what you get is air windows, but it may not be vary rack-y.
Just did a push to clean up a few more things. If you are testing you may want to grab new nightlies ‘more often than not’ as we go. Poly on my radar for today as well as a very good suggestion to have surge style jog buttons amongst the fx.
And, to add the obvious, AW has twenty years of history in environments where the concept of V/Oct (even the concept of V) didn’t, and still doesn’t, make sense. So if Rack-specific adaptations would be helpful here, it seems right (at least to me) to limit them to Rack.
Last time I’ll say “expander” for a while but an “Airwindows filter V/Oct adapter” expander module would be an extremely do-able project for a third-party dev and a good use case either for the name-passing protocol or the 1U version.
The thing I really like about all your solutions @gc3 is that someone other than me will code them up
So lets have Chris and I focus our efforts on getting a clean generic exactly-airwindows plugin into the library then starting a regular update cadence. If that leads to a thousand flowers blooming for ideas, it’s all open code and I’m happy to collaborate.
Exactly 
And not just code them in the first place but maintain them as new algos come in! Better yet, if they fail to maintain them, it won’t saddle the lovely core project with maintenance debt, etc.
So incredibly excited about this!
Yup! I do like how someone suggested the plugin can somehow communicate to a separate plugin ‘I am on this setting, DarkNoise’ so that plugin can swap in a parameter modification. That’d be elegant… though I still don’t envy anybody who feels they need to Rackify all the plugins.
I think you could probably take this, fork it, and override the way it reads ‘Airwindopedia’ to instead read your own local copy, which you could prune drastically? Because that’s really the catch.
I admire the desire to go and tweak everything, and Rackwindows did custom-make 15 FX or so, and tweak them with my blessing and encouragement. Big project. And, every week, I kept adding something else… right now that’s paused for some personal reasons, but it’ll resume and there’s a new Chamber, a new Verbity, an experiment I need to do with ultrasonic-filtered SlewOnly, an adaptation of Holt2 specifically for just adding subs weight without otherwise altering the sound…
It’s great and encouraged to adapt Airwindows plugins and tune them to your purposes. I love it when people do that. But when I mean to support a platform, I need to port and maintain ALL the plugins, every one. And that’s not 15, that’s more than 300. Paul is helping me do just that in Rack, in such a way that it’ll automatically pick up new stuff I add, going forward, without him having to also put in work on a weekly basis to make it happen. So it is the opposite approach… but what you get, for that, is EVERYTHING. Literally every plugin, as is. And that’s kind of a lot, and as I said it’s a mighty deep rabbit hole, but it means I’ll be able to do anything I did anywhere else, in Rack. On the whole, a net win and a good thing
I was just comparing them to the new Airwindows module. It seems like it mostly sounds similar. Tape module though is strange. In the new module it is brighter with lower sounds and a bit darker with higher sounds (compared to RackWindows). Anyway, I love both versions.
Can you tell me what the Floor knob does in the Floor module\submodule? I was thinking it sets the volume of the bottom octave. But it looks like it is a cutoff freq of a filter. Which is expected, cause it’s in the filter category… But i can’t hear the bottom octave at all. It’s saturates the sound though. Adds some harmonics… and DC.
It was a very smooth transition to my bug report!
So here’s DC.
Now if you move the floor knob to 0 and then to max again, the amount of DC changes. Watch!
That’s weird!
Might be useable on control voltages
There are several plugins with naive filtering where you can set the frequency to literally 0. If you do that, you lock in whatever DC is present. Again, this is the complete set of literally everything, all versions, including versions where you could set a lowpass (or, notably, highpass!) from 0 to something and then back to 0 again while audio is playing. And that’s what happens when you do
I see! Thanks! So it works as sample and hold too, haha! Anyway, that’s massive work! Thanks to you and @baconpaul for doing this! You are legends!
WHat I noticed also is that Rackwindows plugins are significantly easier on CPU. But I guess that’s the downside of doing all 300+ plugins in one module…
What i think would be cool is an option of locking the setting. Like say you want to work with 2, 5 or even 10 modules that look very similarly. And you dialled up the sound that you really like on one of them. And then you go to another module changing the programs\plugins and settings. And then you accidently change the program\plugin on the module with a sound that you liked. So it was tape echo and you changed it to some kind of reverb. Well, Ctrl+Z doesn’t work. So you have to go and search for the program that you had, if you remember and then you have to set the knobs again. And then it could happen again if you are unlucky or not very accurate or attentive.
So I propose a toggle that locks the program\plugin
I think the CPU difference is because I’ve set the internal block size (and thus latency) to 4 samples. I think I’ll make this adjustable so you can trade modulation nyquist / latency for CPU.
I should make ctrl z work. I’ll add that to my list.
But a lock is also a good idea.
So three things to add.
I just merged polyphony by the way. new nightly in 20 minutes or so. Polyphony is pretty amazing. Sort of wrong way for the CPU tho
also for “high cpu” modules, examples of settings always help. Like I said I am clamping down on blocks so a lot of chris’ ‘every block’ optimizations don’t help quite as much.
