MIDI controllers and a computer can definitely have their own advantages and can nicely compliment stand-alone hardware nicely.
But stand-alone hardware has some advantage of its own over a MIDI setup.
Well designed stand-alone hardware modules can turn on instantly, you don't have to keep their software up to date, you don't have to do any performance tuning on them or muck around with latency, they don't have to compete with other software running on your computer as software synths do, I can be pretty sure that barring hardware failure they'll still work exactly the same way 5 or 10 years down the line, etc.
In sum, stand-alone hardware offers me a lot of reliability, consistency, convenience, and performance that's often hard to match with a computer and MIDI controllers.
Of course, a computer and MIDI controllers have their own advantages and conveniences, like being able to save settings, having a virtually unlimited amount of functionality by using various software packages or writing your own, allowing the user to change or choose their preferred UI, etc.
So they're really not the same. It's best to have both!
One thing you forget to mention, but were kind of indirectly saying (I think), is the "reliability, consistency, convenience, and performance" leads directly to creativity in a way that in-the-box stuff can't replicate. Personally, I need to get to the sound I'm designing quickly for my creative flow to continue, if I fight the computer's UI (and let's face it, the vast majority of DAWs and plugins have terrible UIs) then it kills it for me. I end up self censoring (not even bothering to try) and the music that I end up making ends up more 'rigid'.
I think if you're the kind of person has infinite patience, then yeah sure, you could probably achieve similar results, but I think for many that's not going to work.
Another aspect is the true analogue modules, which software still struggles to emulate well. This matters for some modules/synths more than others, but there is a quality difference. Again, with time, one could make a digital synth/module sound good, but for me it's the same problem of killing the creative flow.
The line is blurring a bit. Back in the 1990s, hardware modules booted directly from ROM. These days, you’ve basically got a whole computer inside which boots like other modern computers, i.e., slower than it should.
There are also some good examples of software stability. Having used Logic and Reason since the early 2000s, you can see all the care that they’ve taken in never removing anything, and only adding new things.
That's the extra insurance that open source buys you: instead of relying on the proprietary software maker to do the right thing, you ensure that you can always (1) actually run the version you had way back on Feb 22 2020.
(1) yeah, I know things are not quite that simple.
My experience is that the Linux audio APIs have been so volatile that I often can’t run older audio software, even when I have access to the source code.
I have actually composed and recorded music with open-source software, but the cost of doing so was very high, so I switched to proprietary software. Even worse, the open-source software for various reasons has had interoperability problems—you can’t export in standard formats, or that kind of thing. With proprietary software, I was less tied down, since I could export data from one program to another and continue working.
So I’m slowly working on converting the old songs I wrote with open-source tools into standard formats.
The ALSA API (the fundamental device driver layer) hasn't changed in any significant way in more than 20 years. There was one trivial change that might require a 1 line change in a program that happened to use that particular call, but not all Linux audio apps did so.
I don't know what you mean by "cannot export in standard formats", unless you're referring to something like AAF.
AAF is a closed-source proprietary standard for "session files" that fundamentally relies on utterly closed Microsoft APIs. There are some incomplete open source implementations that use a GNU efffort to reimplement those APIs but AAF is also the prime example of design-by-committee. I will never put time into trying to support AAF. Note also that AAF support is missing in major DAWs and users need to rely on 3rd party translators such as Chicken Systems AATranslator (RIP).
If you're referring to standard formats for audio files (WAV, AIFF, CAF and more), then I really don't know what you're thinking of.I cannot think of any open source audio project that has problems with exporting to "standard formats".
ALSA may not have changed, but programs variously have used ALSA, ESD, JACK, OSS, PulseAudio, and aRts. Depending on your hardware, some of these options have been variously unusable at points--too many developers assume that you have a hardware mixer, for example, which is true for standard PC audio output but not true for any pro interface I have ever used (even the dirt cheap ones). At various points, I ended up with audio that only worked with exclusive access. I tolerated it for a while but now I consider it a dealbreaker.
I'm 100% willing to pay Apple to make this problem go away for me. Core Audio is an amazing API.
For cannot export in standard formats--talking about MusicXML. Until a couple of years ago I also had problems listening to music on my Linux system; I think it was because of some patent licensing issue.
All of the above APIs except ALSA run on top of ALSA, except OSS which was deprecated more than 20 years ago. The CoreAudio API has changed just as much in that time period.. there are huge chunks of the CoreAudio API that existed back in 1999 that no longer work or even exist.
Also, note you can't use the audio APIs from macOS "classic" on macOS/OS X (and never could - Apple banned it from the start, so every single audio app that existed for macs pre OS X had to have its audio I/O completely rewritten. Apple didn't pay for this - 3rd party developers did).
I write pro-audio/music creation software for a living, and I can assure you that from this perspective, CoreAudio is definitely not an amazing API. That's without even taking into account the differences between CoreAudio on iOS and macOS.
The only Linux distributions that had problems playing patent-protected formats over the last 20 years were the ones that stuck to a strictly libre software policy. If you picked one of them (e.g. Debian), it's hardly Linux' fault that you chose a distribution one of whose raison d'etre's was to exclude any non-free formats of any kind. I used RedHat starting in 1997 and it never had a problem playing mp3 files.
But stand-alone hardware has some advantage of its own over a MIDI setup.
Well designed stand-alone hardware modules can turn on instantly, you don't have to keep their software up to date, you don't have to do any performance tuning on them or muck around with latency, they don't have to compete with other software running on your computer as software synths do, I can be pretty sure that barring hardware failure they'll still work exactly the same way 5 or 10 years down the line, etc.
In sum, stand-alone hardware offers me a lot of reliability, consistency, convenience, and performance that's often hard to match with a computer and MIDI controllers.
Of course, a computer and MIDI controllers have their own advantages and conveniences, like being able to save settings, having a virtually unlimited amount of functionality by using various software packages or writing your own, allowing the user to change or choose their preferred UI, etc.
So they're really not the same. It's best to have both!