I have sent a bunch of enquiries today down the path of plugin development.
If there is a clear path down that road, I won’t need to build a DAW.
But if I hit dead ends, I might revisit the DAW idea.
I have certainly learned a lot from you and your friends here and for that I am grateful! 
I would like to add that the two main options for DAW creation suggested here don’t seem ideal either.
Tracktion is an old engine, being built in 2002.
If I made a DAW it would be on a much newer engine.
I can’t stand slow software!
And Ardour can’t be made into a commercial product… 
Tracktion may have been started in 2002, but it is under active development to this day.
Old doesn’t necessarily mean slow, either.
Ok, perhaps slow isn’t the right term.
But I was considering doing an audio engineering course in 2009 when Pro Tools was leading the world in DAWs.
Cubase was lagging them at that time.
But Cubase later got ahead of them in terms of features and usability.
Then along comes Studio One with a much newer engine, and is considerably more efficient than either Cubase or Protools.
I have seen CPU testing comparisons using the same plugins and the difference is astonishing.
So from that I have learned to avoid older DAWs.
The only thing that will conclusively tell you how your code performs is testing it.
For an example of a DAW built on top of the Tracktion engine, you can try out Tracktion Waveform, there’s a free version. I’ve not actually produced a track in it myself, but in dev testing it seems to stand up to other DAWs.
If you start playing the game of “I categorically will not use any code written before 2015”, you will very quickly find there are no libraries or tools that fit that description and you’ll be building everything from bare-metal up.
I understand your point, but since we are talking about a very long term project, perhaps starting from scratch with newer architecture would in fact be wisest?
What if in 5 or 10 years, 32 bit programs are made obsolete?
I wouldn’t want to have my entire project built on a DAW with a 32 bit engine, right?
JUCE projects can be compiled to 32 or 64 bit binaries.
You can remake the wheel if you want, but it will take years more and will be filled with bugs, and will have a huge maintenance overhead.
JUCE and Tracktion are already here, made by professionals and used by professionals to release commercial products. Why not use tools available to you?
JUCE is currently the best option for VST3 plugin across all DAWs and platforms.
They don’t even seem to have any serious competitors.
However, I need to look at all the options and weigh up which would be best for my project.
It might turn out that a standalone Windows app is the easiest and cheapest solution (although far from ideal)
Steinberg seems to have a monopoly on VST3 plugins and seem to have made my idea nearly impossible.
If someone asked me to build a standalone app, I would use JUCE to do it! I don’t know why you’re positioning this as an alternative to JUCE – JUCE is a tool for making standalone apps, as well as plugins.
Well, yes, Steinberg created and owns the VST3 specification.
Ok, I didn’t know JUCE could be used for standalone apps.
What advantage does it offer, compared with building one directly in C++?
The same as it does for plugins: it’s a set of high level building blocks to allow you to build things quickly, and cross-platform, so you don’t have to use low-level system APIs.
So it’s kind of like the Wix equivalent of website building?
I think if I was to code it myself it would be more attractive, as I would want the easiest solution.
The big downside would be lack of flexibility, right?
If the idea I have isn’t possible with the existing JUCE package, then I’ll be stuck.
While if it’s done in C++, my options will be nearly unlimited, right?
JUCE is just C++ code.
Any lack of flexibility I’ve encountered when writing plugins in JUCE is due to various plugin formats and hosts, not the JUCE API. You would encounter the same limitations if using the VST3 SDK directly.
JUCE does not limit flexibility. If anything, attempting to build your own app from the ground up would limit flexibility, and here’s why: you’ll end up creating your own framework that does what JUCE does, but without all the documentation that Juce has, and attempting to bring new people into your team will have a huge learning curve, whereas there are plenty of developers who already know JUCE.
From what I have seen, JUCE seems to focus on DSP, and my app would not (although DSP might come in handy for later developments).
I suppose my biggest fear would be when I want to create X function, I find out, “You can’t do that in JUCE”, you would need to make a program in C++.
And then I’m back to the drawing board!
JUCE has lots of DSP tools, but you can use it to build literally any kind of plugin or app.
You can call any C++ code from JUCE. JUCE IS C++ code.
Ok, that was very helpful.
If I want to learn what JUCE is capable of and what “building blocks” are currently available, where would I find a good overview?
I’ve found some videos on youtube and they dive into the coding too much to be helpful.
Here is a list of every class in JUCE.
Hey Ben,
If I hired a programmer, I would prefer to use a website like Freelancer.com, as it has a powerful search function and gives much information about the programmers.
However JUCE doesn’t appear in their search function.
I have written to them about this with no response.
Do you think someone from JUCE could contact Freelancer and get it included?
It would make it so much easier to find a good coder that way.
For example in the Skills section, I can enter C++ but I get 56421 people!
It would be better if I could narrow it down to those proficient in JUCE.
If you want to hire a JUCE programmer, the best place to do that is here on the forums. There’s a “job postings” category.
I’ve never used Freelancer.com, but my impression of sites like that is that they are intended for one-off gigs, not a long term project that may span months or years.
