Is VST support on the TODO list? about stargate

Basically, the choices were:

1. Maintain complete control over my own ecosystem, enable many unique and exciting features like support for every OS and CPU, projects that can be easily shared, CPU usage low enough for Raspberry Pi and 15 year old laptops...that would simply not be possible if I supported VST because almost none of the VST developers support these same features and experiences.
2. Write yet another VST host that nobody asked for, attempt to compete in a crowded market with companies that hire dozens or hundreds of full-time software engineers, commit to following whatever Steinberg does with their API standards, attempt to support thousands of existing plugins, many of which I would have to purchase to be able to support in a meaningful way. Implement a gimmick or two and hope that it attracts a loyal fanbase before the other VST hosts copy it.

I chose the first option, for reasons documented HERE. Of course, there are already 16 included plugins (one of which is a modular multi-effects unit with over 30 effects). In the future, there will be many more plugins exclusive to Stargate DAW, all of which will continue to offer big sound at a fraction of the CPU usage of competing plugins.

There are already plenty of fine VST hosts, the world did not need another one. Producers who want innovative and unique experiences can choose Stargate DAW. Producers addicted to the same old FOMO and GAS of the VST ecosystem, who believe it's only music if it's made with this summer's hottest new VST plugin with the prettiest UI, I encourage to continue using FL Studio, Ableton and their sprawling collection of VSTs.

[CHJ85]

You're absolutely right. Well answered, and thank you.

[mxmilkiib]

Zrythm DAW uses Carla host behind the scenes to manage various external plugin formats. Maybe that potential option might not vibe well with a closed ecosystem principal, though it certainly would assist in reducing the work required to implement plugin hosting. A thought anyway!

Zrythm DAW uses Carla host behind the scenes to manage various external plugin formats. Maybe that potential option might not vibe well with a closed ecosystem principal, though it certainly would assist in reducing the work required to implement plugin hosting. A thought anyway!

It's a good idea if we go this route. I looked into it a bit yesterday, the Carla downloads for Windows and Mac are 250-300MB. For contrast, Stargate DAW for Windows and Mac is only 30-40MB, it would 10x the size of the downloads.

I'm not sure why the Carla downloads are so big, I did not analyze it yet. Could be that they use and bundle a lot of libraries, or contain a lot of large image files, or bundles a bunch of plugins. Maybe we could mitigate some of this bloat by packaging it ourselves, or maybe not.

Of course, adding any kind of external plugin support will break the following unique features of Stargate DAW:

• Projects are completely portable from one computer to another
• Projects are completely durable, can be opened and edited 10 years from now or 100 years from now
• Full sized projects can be run on very low end / old hardware
• (If using Carla) Tiny installer files suitable for people in countries with very limited internet bandwidth

I am not convinced that entering the metaphorical rat race of VST hosts is the path to success. Sure, all of the most successful DAWs do it, but so do most of the failed/failing/struggling/unprofitable DAWs.

I was talking to another developer, who contributes to a major open source DAW, he also wanted VST support. I will extend the same offer I extended to him: Supporting the entire ecosystem of VST plugins on 3 platforms is a huge undertaking, that I am not willing to take on by myself, it's literally easier to write 100 plugins than to support thousands of 3rd party plugins.

However, if other developers wanted to join forces and take on VST support, I will provide my full support to a fork of Stargate DAW (call it: VSTargate DAW). If VST support for Stargate DAW turns out to be as wildly successful as everybody assures me that it will be, I will shut down the main project and humbly join the fork.

[windowsrefund]

Please never support VSTs and keep up the great work. The design principles (I just read them) behind this project, along with the fact it is licensed as free software, is absolutely inspiring!

[CHJ85]

@windowsrefund Why are you against VSTs? You know those are optional, right? It's not like they're baked into the program. Because I do agree with the free software philosophy. Adding VST support wouldn't change that. So Idk what's you're talking about.

[windowsrefund]

I read the project's design principles.

[CHJ85]

@windowsrefund Right, but the project is still free and open source. Allowing proprietary plugins such as VST doesn't change that. Plenty of FOSS projects allow VST's, such as Audacity and Ardour.

[appetrosyan]

Maintain complete control over my own ecosystem, enable many unique and exciting features like support for every OS and CPU, projects that can be easily shared, CPU usage low enough for Raspberry Pi and 15 year old laptops...that would simply not be possible if I supported VST because almost none of the VST developers support these same features and experiences.

If I recall, there was a line in Hamlet about locking oneself in a nutshell and declaring oneself a king of said nutshell.

Since the project is in its early days, it is still possible to avert irrelevance.

[windowsrefund]

There are really only 2 choices here.

1. Read (carefully) the project's stated design goals and respect them.
2. Using the freedoms provided by the license, fork the project and bastardize it as you see fit.

Pretty simple.

[appetrosyan]

OK.

There are really only 2 choices here.

Four actually. And in order:

1. Respect the developers’ wishes, and refrain from comments about dumb ideas sounding less dumb if they’re part of a “vision document”. But I will not refrain. The "carefully" part, is a bit uncharitable and I'll return you the favour. Refusing to do VSTs early on, is a signal that you don't understand the niche. It's like refusing to build a car with wheels. It tells me that not only are you bad programmers, you confuse lack of research with vision. This is great if you're going to build a startup bubble. Good luck with that.
2. Assume that VST integration isn’t actually hard, and that the project, as it stands now, contains any useful code, so that forking it would make sense. I'll be charitable and say that Python script kiddies with delusions of competence are a dime a dozen.
3. Wait until you realise that most musicians use the DAW as a UI for VST/AU plugins, and that nobody will be making plugins for you, unless you spend time on it. Thus forcing you to revise your “design” document. I’ll wait. We were all young and made mistakes.
4. Use a DAW that actually supports what 95% of musicians use them for.

Wish you guys best of luck! You’re gonna need a lot of it!

[fewtubefx]

What about supporting CLAP pluigins?