Can't wait to get a seamless setup for it, but I guess 0.3 is still too early for early adopters...
As others have noted, Bitwig already exists - in some ways, it is more powerful than Live (and in others, less). It is also proprietary.
Also, Live is not the kind of tool that most people would associate the term user friendly with. It's quite hard to get started using Live, despite the program being basically 100% awesomesauce. Live is extremely friendly towards a certain kind of workflow for "in-the-box" music production, and has fundamentally changed the entire zeitgeist surrounding making music with computers. But it's not a replacement for linear timeline DAWs (like ProTools, Logic, Sonar, Ardour etc. etc.) and has its own foibles and certainly its own complexities and limitations.
I anticipate that the next major release of Ardour will have some Live-like features starting to arrive.
This is pretty intriguing - is there a public roadmap for these Live-like features ?
Slowly I'm trying to get https://ossia.io there... any help appreciated :D
And for the record, the open source audio community is not dead. There is activity, but you have to know where to look.
[0]: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...
JACK is an exceptional powerful tool (if I do say so myself) but it is overkill for the majority (maybe even the vast majority) of users. We try to encourage most Ardour users to use its builtin ALSA audio/MIDI I/O support rather than JACK these days.
For me JACK was a huge step forward. After 25+ years of recording on tape, JACK allowed me to switch to computer based recording ~14 years ago. It did away with a lot of the arbitrary restrictions on what connections were allowed in the audio software that was around at the time (and which made me unwilling to switch until that point).
Edit: sidenote is there any software works with a mixtrax3
ALSA is horridly complex and it's complexity is related to Linuxy stuff, not to anything resembling the work your actual audio converters are doing nor the task of getting data in and out of them!
A new layer added on top of ALSA will not fix this.
Nothing will fix this until some AUDIO people, who are NOT Posix Linuxy People write a realtime audio subsystem to REPLACE ALSA.
This will not occur anytime soon, for several reasons.
Both the Bela.io system and Elk's "brand new audio OS from the ground up" (LOL) utilize Linux but bypass ALSA to achieve their low-latency rock-solid audio pipeline. (the CTAG interface that Heinrich Langer designed appears to be the first example I can find of this approach)
They use Xenomai realtime kernel extensions to Linux to essentially run the audio driver as a real-time thread and the buffers your program writes to/reads from, are the actual buffers that DMA is moving the audio data in and out of to the ADC and DAC.
End of the day, audio isn't a posix API, and should never be considered as such. Want an abstraction? fine, wrap a callback as an audio server lol...
I had a Tascam USB audio interface that always sounded THIN on Linux and I wondered why, until I saw that the ALSA channel mapping had automagically applied a surround sound map to my 8 channels of output, which implied two lovely high-pass filters running at 75hz because the system was quite sure that's what everyone does with 8 channels of output... this despite the fact that ALSA saw 4 different stereo "devices" as my hardware interface presented itself...
IF ONLY this were merely a universally understood /etc/alsa.conf or something file... oh no no no! Linux People have SAVED us from audio configuration! Go look in /opt/didntknowthisfolderexisted/.confy/map.conf or maybe somewhere else... Add x-windows and the lack of any GUI application corresponding 1-to-1 with the "handy obscure utility" it purports to configure and control, and you have a match made in heaven!
Linux is an awesome server OS. It's a crap audio OS, and this is due to extreme cleverness and a total lack of paying attention to how any other audio API's in the world work except OSS... OSS isn't even an audio API FFS! it's like a printer API... you might as well use CUPS to run your sound LOL
Things like JACK (which tend to draw complaints) don't exist on other platforms (except ... by running JACK there), so complaining about its complexities (not that you did, explicitly) isn't really fair since that is based on an apples-to-oranges comparison.
I would guess that the options you miss are the result of application and plugin developers (not) being willing to include Linux in their target platforms. As cool as PipeWire might turn out to be, it isn't going to have much effect on those decisions.
Finally, lots of people seem to manage to forget how for years (decades, perhaps), high performance audio software on Windows required new device drivers (ASIO) for your audio hardware, because the ones that came with Windows couldn't do the job. This has mostly changed now, but ASIO is still with us nevertheless.
With ASIO on Windows, all the user need do is install the driver and then select the ASIO device in their application. On Linux, if something is wrong with your ALSA config, you need to break out the text editor and become an expert in ALSA architecture and configuration. I've seen enough lost souls in this situation asking questions on mailing lists that I am convinced it is a major problem.
As someone interested in deploying an end-user application to Linux, the fact that there is no plug-and-play "it just works" solution[2] for low-latency audio is a big problem.
[1] More specifically: resolving misconfiguration.
[2] By this I mean a solution that works by design, not by luck.
