On Tue, 05 Feb 2013 09:58:14 -0500 Dave Phillips <[email protected]> wrote:
> ... > > So, in your honest and bold opinion as user and/or developer, what do we > lack most and what can we do without that we already have ? Please feel > free to expand your remarks as you like. I'm planning an article on the > topic and will likely use selected comments, subject to approval of course. Too much fragmentation/too many standards to choose from. Plugin formats for example. There is LADSPA which is all good and very useful for its special niche, but it lacks the ability to create proper instruments (as opposed to filters, for which it works fine). Also LADSPA has no support for GUIs. Then there's DSSI which has support for instruments as well as GUIs, but it lacks certain other things which other formats such as VST have had for ages; one thing I was missing was the ability to pass tempo information to the plugins. Then there's LV2 which is so complex with all its "extensions" and Raptor and whatnot that as a consequence, almost nobody supports it. I remember a discussion on the Renoise board where the developers said that they would not support LV2 plugins specifically because it was so complex and it would pull in so much bloat for so little expected gain. They chose to support DSSI instead, with all its limitations. Then there's native Linux VSTs of course. There are few, mostly because Steinberg can't be arsed to make their API/SDK available in a way which makes painless open source development possible (this is not the "fault" of Linux audio of course!). Then MIDI: There's ALSA Midi which most programs use, and Jack has its *own* implementation which is incompatible with ALSA, which means that ALSA Midi programs can't talk to Jack Midi programs and vice versa. (Yes, there are "bridge" applications and stuff, I know...) Same thing for session management. The way JACK is built asks for modular connection of apps, but there's just no way you can reproduce that song reliably once you have it all setup. There's LASH, at least one other session management, I forgot its name, and recently JACK began to grow its own session management extension (only available in Jack2, but not in Jack1, right?)... For the best chance of good compatibility, an app would have to support ALL those session management interfaces. Many don't even support one. Then JACK is great for what it does, but it really is a pain. It's hard to setup, and sometimes it and its tools are just plain buggy. At the sublab (local hackerspace) we tried setting up a moderately low-latency audio server which networked computers could talk to using Jack. I remember night-long debugging and setup sessions for that. Once, everything seemed to be running alright but there was no output. We found that the jack.plumbing tool had been crashing instantly after starting for some reason for a while, so connections weren't restored. I think that was fixed when we switched to Jack2. NetJack apparently doesn't work when the clients are across a router; it has something to do with the TTL of network packets which are used to discover the server. I wrote a patch for it, but we would have to patch the "server" machine (which isn't called the server in Jack terminology I think) and all the clients who would be using it, plus configure the router to forward the packets. Of course, we also want to just stream music at times, for which Jack is overkill (and not all music apps support/not all users want Jack), so we have to support PulseAudio too. We now have PulseAudio running on top of Jack2 which is sorta stable but it took ages. Jack2 seems to be more stable than Jack1, and the network support is better IMHO. I'm a professional software developer and I sometimes also do some server configuration stuff and the like, but even for me, Linux audio is often just too complicated to be fun. Especially when I'm in a "musical mood", I don't want to think about port forwarding, segmentation violations, problems with session management interfaces, bugs in low-latency kernels, crashing Wine plugin bridges which worked last week before the automatic update ran, and stuff like that. When I'm trying to do music, I want to think about *music* and about using technology in creative ways for making music, not staring at stack traces. And I think this is a problem that will not be fixed by creating some wrapper script with a nice colorful GUI or even creating one more distro with a realtime kernel and audio-specific default settings. Usability is something that has to be thought about and built into the core interfaces and programs such as Jack from the beginning. This became something of a rant, sorry... I don't mean to be rude, there is great potential in Linux audio, great stuff has been done by many people in the last years, and I would never switch to Windows or buy an Apple so I could use "The Audio App" (Live) like most everybody else. But sometimes I think the huge great efforts made by Linux audio people could be better coordinated to yield more, faster progress. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
