mirror of
https://github.com/airwindows/airwindows.git
synced 2026-05-15 06:05:55 -06:00
[GH-ISSUE #23] Just a thank you, not an issue #17
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/airwindows#17
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @baconpaul on GitHub (Dec 11, 2020).
Original GitHub issue: https://github.com/airwindows/airwindows/issues/23
Hi!
Please feel free to just close this issue, but I just wanted to drop a note to say
This makes Airwindows available both in Surge proper and the FX bank we have (which runs all the surge FX as a standalone VST3 plugin, of which Airwindows cluster is one such effect).
Full beta announcement is here: https://surge-synthesizer.github.io/beta18 with link to our full changelog.
So we on the surge team just wanted to drop a note saying: thank you for making such great sounding and entertaining plugins, and thank you for making them open source so we could adapt them to our signal path easily!
Have a safe and happy end of year
@dromer commented on GitHub (Feb 20, 2021):
Oh wow, this is actually really cool. Do you think it's possible to reflect your effort back and get https://github.com/airwindows/airwindows/issues/14 resolved? (individual airwindows plugins as vst3)
@baconpaul commented on GitHub (Feb 21, 2021):
That's quite a bit of work and requires writing VST3s for each effect. And that would have to be in a separate repo "north" of airwindows (like surge is north of airwindows)
BUT if you download Surge it comes with the SurgeEffectsBank which is a standalone version of our effects units. These include the AirWindows. So defect the Surge multi-effect unit comes with the 59 AW effects we chose shipped as a VST3. They have the weight of the other surge FX also but at ::process time that's not something you pay.
And editorializing: The VST3 SDK is "hard" to work with. We are in the process in surge land of moving from a hand rolled VST3 to Juce (the SFXBank is actually a Juce plugin). So if Chris or someone else were to ask me how to resolve #14, I personally would suggest a combo of cmake, juce, and some code tricks like we played in surge to make a more adaptable generic from the (incredibly well organized) airwindows code to make a raft of JUCE plugins automatically from the codebase here.
@dromer commented on GitHub (Feb 21, 2021):
Yes, I know of the JUCE port of Surge (I think we've talked about it ;) ). Maybe porting airwindows to JUCE would indeed make it easier to adapt to other projects (since ~90% of audio plugins or standalone tools use JUCE in some form these days).
Glad to take the SurgeEffectsBank for a spin sometimes. It's great that people are adapting the airwindows code to their projects. But since Steinberg is quite aggressively trying to get rid of vst2 it would also be great if the original project can stay alive/useable just a bit longer. :)
(Having a single code-base where specific plugin-formats could be derived from would certainly make it much easier to maintain the project. Right now the code-base consists of 4 near duplicates - one for each build - which is kind of insane from a developer standpoint.)
@baconpaul commented on GitHub (Feb 21, 2021):
Insane is a bit strong. But yeah one can imagine a different factoring.
the way I did the surge port was use the Mac VST2 on all platforms and then write a fake vst wrapper around it which adapts the api points to surge internals without using steinberg code if that helps.
@dromer commented on GitHub (Feb 21, 2021):
Well ok, maybe not "totally insane", but consolidating those 4 directories would help a lot. Thing is that there are SO many plugins to go over! :)