On Tue, 1 Sep 2009 11:51:13 -0500 (CDT)
Brent Busby <brent@email-addr-hidden> 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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Wed Sep 2 00:15:02 2009
This archive was generated by hypermail 2.1.8 : Wed Sep 02 2009 - 00:15:02 EEST