Feature Request: airwindows for the upcoming 4ms MetaModule

[offthesky]

Would love to be able to leverage the absolute awesomeness of Airwindows VCV effects within the upcoming eurorack module! I'm no coder so I wonder if this could this even be possible?

https://github.com/4ms/metamodule-plugin-sdk

[baconpaul]

Haven't heard of it until 3 minutes ago but the readme is pretty clear.

1. The no-nanovg-draw constraint means the UI isn't portable
2. We use cmake so they are in luck there the build looks pretty easy
3. My guess is the way to do it would be to use the underlying lib and write a new top level module for it, since also things like polyphony support will just get in the way

I don't use physical eurorack so I'm not the person to do it, but from reading that readme, it sounds like an experienced rack programmer with one of the devices, a few cups of coffee, and a week, could make something work reasonably well, and if someone wanted to tackle that I'd be happy to give them pointers and answer questions.

[offthesky]

thanks for the response!! well that's good to know it's at least doable in some way... i can maybe try and pitch the idea over to 4ms somehow(?), since there's so much amazing goodness in this one airwindows module (i mean, just the reverbs!) im sure they'd love to have it working on their module. although im sure they have their hands way full at the moment. finger's crossed it can happen in time.

[baconpaul]

If you find a dev who wants to do it, from reading their doc, it doesn't look hard. Send them here and I can tell them how I would tackle it. Looks eminently doable.

From reading their blog, I would actually not do it with the rack module but instead do it with the underlying fx library we build which we share between the rack module and daw plugin. So make it a "third" thing this repo can build which wraps up the effects and effects registry. Then you get a better chance at a 4ms friendly screen. But like I said, that's just from skimming their docs.

[offthesky]

i'll do my best to try and get 4ms (or some such saint coder) on board and send them your way! i think the benefit of having upwards of 300+ effects in one awesome module for the hardware format, would be amazing for everyone. even if one cannot really edit the AW module directly on the MM due to whatever ui/ux limitations of their platform. 4ms actually stated the best work flow being: create the patches on your PC<perform live with them on the MM.. so i assume a lot of modules that get ported down the road- ones that require a lot of mouse input like gesture recorders, or ones with deeper menus (maybe like AW)- will just have to be setup in VCV on a computer but not be able to be edited much further inside the MM? dunno. anyway, fun stuff to think about; really appreciate your considerations here!!

[offthesky]

also fwiw, i was a ui/ux designer for 20 years so in any case (with whoever wants to tackle this) im happy to assist in the graphics porting dept!

[airwindows]

Tell me you don't know anything about Airwindows without telling me you don't know anything about Airwindows :D

In no way do I mean for that to make you unhappy… on the contrary.

This sounds like the neatest side-effect ever, and you should be pleased to know the entire Airwindows library, even as it expands by roughly a plugin a week, comes from individual no-GUI plugins of very consistent design to make them easier to work with for stuff like this.

There's quite a few plugins that literally have no controls, and none that have deeper menus in any sense: if you can edit a maximum of ten simple 0-1 sliders within the interface (or fewer) then you can use the full functionality in this new context. It sounds awesome. I'd buy 4ms modules that could do this.

The plugins so far all run and are initially developed on an antique Mac laptop running Snow Leopard, and are compiled (no guarantee about running) on Raspberry Pi, so I imagine whatever 4ms are doing, they can run the code. There is no special mouse input or gesture recorders, no menus, nothing. There is no GUI so there's nothing to be ported, make something up to taste, whatever you like :)

I'm reading the 4ms page now and can attest that for every single limitation, there is literally no Airwindows plugin that would even need to be recoded. Every one should just work out of the box if the overall structure can be made to work. if you can do say Pafnuty2, you can do literally every one. Out of a script, even.

Keep me posted on how it goes and I'll keep making the initial modules! Those are coming along quite well :)

[baconpaul]

yeah exactly chris. and the library-build underpinning the daw and rack plugin is a uniform package that lets you interact with the plugins directly, without a ui or framework in the way. 4ms should start there i agree.

[offthesky]

i do in fact love/use the AW vst on a daily basis (TY! REALLY love the consolidated one btw!) and for years have quite appreciated the no-gui-simplicity of it as im a big proponent of the whole see with your ears thing :]

i just mentioned graphics help- only referring to any sort of svg's in the case of porting the vcv module over to the metamodule format..

[offthesky]

i've gone ahead and mentioned this thread to 4ms elsewhere- i'm sure they'll add it to their list (as they've mentioned adding/future porting several other vcv module brands to MM) and so we'll see, in time. fingers crossed!

[danngreen]

Airwindows has been on our "list" to look into porting, I just got wind of this conversation so I'm looking at it now! Wow, impressive list of audio plugins!

As @airwindows is saying, it looks simple enough to port the original plugins to MetaModule format: we would need to create or generate front-end graphics, and create an adaptor layer.
But... the issue is figuring out how to tie the MetaModule's version of AW to the VCV Rack version.

In VCV Rack all the AW plugins are all one module, but on the MetaModule we don't have any way for a module to dynamically change its parameters or jacks. So we'd have to just display a generic faceplate and the maximum number of knobs/jacks. The audio and controls should work just fine, but there would be no help from the screen as to what the jacks/knobs are. Not sure that's the best idea.

I like the idea of creating a separate MetaModule module for each AW plugin, but there's not a way to have the MetaModule load a different virtual module depending on a parameter in the patch file (I presume the currently loaded AW plugin is saved in the VCV module's dataToJson())?
It might be possible to have the VCV Rack MetaModule "Hub" module (which is what you use from with VCV Rack to create jack and knob mapping and save a MM patch file) to "know" about the VCV AW module and to read the parameter for the AW plugin selection, and then generate a patch file that uses the corresponding MM AW module. If that makes sense.
Still wrapping my head around it, but seems do-able.

@baconpaul does the airwindows-registry static library seem like a good place to start? Or just use the original source from https://github.com/airwindows ?

[baconpaul]

So I think you shouldn’t use the rack plugin. The static library is the starting point. It underlies the rack and juce plugin both and could just as easily underl one or a set of 4ms plugins. I would definitely stat there.

[danngreen]

Got it. Yeah, I think having multiple MetaModule modules is the way to go.

I looked at this repo some more. Now that I see the scripts that convert the Mac VST to the static library format, the relationship between the projects all makes sense now. I got the static library to compile for the MetaModule architecture (32-bit armv7a), with some minimal changes, pushed to a fork:
https://github.com/4ms/airwin2rack

Next step is to make an adaptor that generates a MetaModule plugin from the registry (we do a similar thing for our 4ms modules).

[baconpaul]

That looks eminently mergable with a quick ifdef for the string to float and a cmake argument which sets a -D - happy to merge it so you don’t need to maintain a fork too with the obvious tweak or two

[baconpaul]

And all very exciting!

[danngreen]

Great! Not having to keep a fork in sync would be ideal.

I realized we don't need the cmake stuff to happen in the airwin2rack repo, since the static library is included into the plugin target, it can be given the arch and toolchain flags there (i.e., here: https://github.com/4ms/metamodule-plugin-examples/blob/airwindows/Airwindows/CMakeLists.txt). So, I reverted those cmake changes.

a quick ifdef for the string to float

You mean an ifdef to use the original version vs. the non-throwing versions?

Once that's done, shall I open a PR, or how do you prefer?

[baconpaul]

Yeah on c++17 that strtof can throw so we need a libc throws macro and annifdef there basically

and yeah please do just open a pr. That will let me kick off ci and I can merge easily

cool stuff!

[danngreen]

Got it. I used the same macro test that CMRC uses for its exception testing. LMK if you want to see something else there.

PR is open!

[baconpaul]

OK @danngreen I merged the PR. Thanks!

Chris updates this repo automatically every week when he does a release, which grows the static library and registry. Right now the only option in the static library is to include every effect, but I have on my list a cmake option which would let you pick and choose a sub-set for a static library build also. If you end up running into needing that, please open an issue and I guess Is can accelerate that bit of the work. But otherwise I think you are good!

If you are looking for some effects to test with, I usually use Galactic (because the tail is super long) and ZLowPass (because it sounds great) and then one of the distortions. But if Galactic renders properly you have things hooked up correctly.

Look forward to seeing what to do! I'm happy to leave this issue open for discussion or for you to close it and we can go issue-by-issue after that.

[baconpaul]

Oh and I squashed when I merged so you will either need to delete your fork (best) or hard reset update your main.

[danngreen]

Thanks! Excited to hear these run on hardware...
We can just use this issue until I get something running.

[baconpaul]

yeah exciting! If you get a demo up on YT or something please do share. I'm sure Chris and I would be thrilled to see it.

[danngreen]

Ok! Made a lot of progress on this. The registry makes it easy. And wow, what a treasure trove of cool sounds!

I made an adaptor between the airwindows_consolidated_base and the MetaModule's CoreProcessor class, and then, boom! All 398 modules load!

I've only audio-tested a handful of the modules, but Galactic sure sounds nice! I posted a (rough and therefore unlisted) video:
https://youtu.be/EnJMSFuN9eo

The generated artwork has some rough edges and needs some help. The last 30 seconds is me just scrolling through all the modules, clearly I need to add some layer of organization here, maybe draw from the category tags in the registry.

Processing load is surprisingly low, at least for the modules I've tested so far.

Right now I have the airwin2Rack repo as a submodule within my own plugin examples repo:
https://github.com/4ms/metamodule-plugin-examples/tree/airwin2/Airwindows
I had to add one more #ifdef to my fork of airwin2rack, because there currently is a limitation where the custom libstdc++ we use for dynamic linking and loading doesn't work with iostreams. But I hope to fix this on my end. We could probably build the MetaModule plugin from within airwin2rack, but I don't know which way is better. For now I'm happy it came together so easily.

[offthesky]

https://youtu.be/EnJMSFuN9eo -BADASS!! so glad this worked out and absolutely stoked (and im sure the entire community as well) to be able to leverage these effects on the hardware!

[baconpaul]

OK so

1: Amazing.
2: Yeah use the registry categories. They are automatically updated from chris' documentation
3: I'm happy to add a src-4ms directory same level as src-juce and src-rack if you want but submodule is also fine. Just make sure to pull your submodule fairly regularly since Chris releases a new effect a week or so and auto updates this when he does. Also happy to merge any changes you want as long as they are appropriately ifdefed. ifdefs >>> forks
4: Did I say amazing? Oh yeah. But let me say it again
5: You don't happy to sell these in a guitar pedal form factor rather than a eurorack factor do you? I would press buy faster than you can imagine if so.

[danngreen]

Thanks! Yeah and thank you for making this so easy!
I'll figure out where to put the category tags.
And then I'll take some time to cleanly upstream my changes and open a PR. Hopefully not too many ifdefs!
Ha, we are considering a few form factors for this... guitar pedal would be cool. Also a tiny standalone thing (3.5mm)

[baconpaul]

Great

A programmable guitar pedal with a small display in a mid width stomp box would be on my board faster than fedex could get it to my house. But even if you never do that (and it may be a terrible idea! Hardware sales is terrifying) I'm still super glad you can get this to work.

Send a PR when you are ready. Happy to review and merge as you need.