On Tue, 1 Sep 2009 11:51:13 -0500 (CDT) Brent Busby <brent@xxxxxxxxxxxxx> wrote: > On Tue, 1 Sep 2009, Patrick Shirkey wrote: > > > This is interesting info but imo the question is whether it is > > necessary to completely emulate the AL system in order to enable AL > > like live performance or is it more a case of taking their ui model > > and integrating it with our existing apps to provide a similar > > experience that AL users can easily grok? One of the things that AL > > users are attached to is the ability to quickly get up and running. > > I think we have a lot of that ground covered already but from a > > n00b pov it's a daunting task to get started with a pure jack'ed > > setup using multiple apps each designed for a specific purpose. > > Mostly because they have been taught a unified approach from using > > the dominant monolithic products like AL, Pro Tools, Logic etc. > > > > I feel that cleanly integrating a sampler interface with existing > > apps will provide a competitive Linux based solution. > > Probably the only thing that's confusing to them is the process of > starting everything up and getting it communicating. I can't imagine > that having multiple apps running on the same desktop is that > confounding to the average Windows user. > > Maybe what's needed isn't so much an app with an integrated UI as > some kind of wrapper that launches everything and offers some sane > default profiles (which can be saved and edited also)? It's nothing > that someone familiar with scripting couldn't do themselves, but > maybe that's the assumption that's causing trouble -- that all of > this is so simple to do in a 5-minute bash script that it'd be silly > to provide as a package? It might not be silly to some users. That > package could depend or recommend others through dependency. > Installing it could trigger everything necessary to get up and > running for a new user. That's why lash would be a good thing. But now that the efforts got divided it probably slipped even further into the future. > These are just suggestions, just in case someone here feels on the > verge of writing some Live-like program that tries to roll all of the > common tools into one GUI...maybe it's not necessary for some > purposes. > > Of course, a realtime-enabled kernel should also be part of that > recommended set of packages that get triggered. In theory, that's > already being done by music-oriented distros, but after seeing Ubuntu > Studio get that so horribly wrong, it can't be taken for granted. > It's the other hindrance: In 2009, realtime is still an issue. It > shouldn't be, but it is. I even have a tendency to want to consider > it solved myself now that I've got my own system working (someone > else's problem now for me...buhahaha!), but if you look at the forum > posts over the years, it's the one subject that keeps coming up. If > it wasn't true, talking about latency would be boring, but instead > it's almost all LAU is about. To me it looks like LAU just mutated to ALA, Ableton Live Advertisement. > People come here and they talk about > achieving low latency...still. Nope, it's not all about low-latencies, for many the stock kernels work pretty well and are often more stable and I guess performancewise similar to what other OSes provide > Give them a out-of-the-box realtime kernel and a GUI > launch/interconnect manager for their audio apps and they will come... Those are all there, just a real session management is missing, and I'm quite sure that it won't ever happen as long as it stays a one-man-show or multiple one-man-shows. Instead it would need a collaborative effort, including those developers who actively develop the main linux audio applications, nothing less. Philipp _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
