1 Sep
2009
1 Sep
'09
5:35 p.m.
On Tue, 1 Sep 2009 11:51:13 -0500 (CDT)
Brent Busby <brent(a)keycorner.org> wrote:
On Tue, 1 Sep 2009, Patrick Shirkey wrote:
That's why lash would be a good thing.
But now that the efforts got divided it probably slipped even further
into the future.
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. 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