23 Jan
2008
23 Jan
'08
5:21 p.m.
On Wed, 2008-01-23 at 19:44 +0200, Juuso Alasuutari wrote:
There's no reason to add a system-specific API layer to LASH itself.
The abstraction could be done by a separate library entirely, eg
libeasyjack.
I must have been thrown off by Nedko's words "LASH should behave like
all-in-one app" ;-)
The thing is, a lot of the problems that have been highlighted as
capable of being solved by LASH aren't really anything in LASH's domain
and *shouldn't* be solved by it.
For example, yes, you could add support for maintaining the specific
settings of the patch system (I'm referring not just to JACK here) but
that's not what LASH is concerned with. It only cares about patch
configurations and client state. If it's the case that LASH *has* to
control the settings of the patch system just to provide a usable
system, then it points to a problem with the patch system. If the user
wants to change settings on the fly then the patch system itself should
enable that.
IMHO, there is a lot of work to be done to properly provide the kind of
support that LASH is *trying* to provide, without going on and thinking
about what else it might be able to do. Here is the list of future LASH
work from a while back:
1.0
Client priorities
Track naming
Guaranteed save directory availability
I'm getting the feeling that there have been some
misunderstandings in this
discussion. Let's see if I can help with them, or if I'll just end up
confusing things more. :)
On Wednesday 23 January 2008 00:18:48 Bob Ham wrote:
It sounded suspiciously to me as though that was exactly what Nedko's
proposal was :-) As I understand it, the issue is that jackd crashes,
and when it does it tends to bring down the whole audio session which is
a nightmare from a usability perspective. Nedko's proposal is to create
some system outside of jackd that can account for those crashes and
maintain the audio session in spite of them.
I think this is wrong. It's saying "OK, jackd isn't robust and we're
going to take account of that in our JACK-dependent system" when what
should be said is "OK, jackd isn't robust so we're going to make it
robust."
On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov
wrote:
I don't think Nedko's proposal is motivated by a desire to work around
existing bugs. Bob Ham <rah(a)bash.sh> writes:
A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.
To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up? More generally, LASH isn't a frontend for
JACK.
What about the jack watchdog? What does get killed by it? A layer that
abstracts away the incidental
obligations of being a JACK client would be good but that is very far
from the domain that LASH is intended to help with.
If such a layer could be beneficial (which is my belief also), why do you
think that it's outside the scope of LASH planned improvements? To view LASH
as the centre of a linux audio system is to misunderstand
its purpose. It might be able to *facilitate* a unified system, along
with JACK and other APIs, but it isn't the unified system itself. Such
a role is intended for the much-loathed "server interface" distinguished
in the LASH API.
I personally don't see LASH as the centre of the audio system, and I'm not
sure that Nedko meant to say that either. It seems that
what you want is Patchage++. Unfortunately, LASH isn't
that and I think you're likely to run into problems if you try and turn
it into that.
Yes, at least I would like to see the day when one application can manage
everything that the concept of an "audio session" includes (Patchage is
probably pretty good already). But you've misunderstood the purpose of this
discussion. We're not out to turn LASH into a super daemon/application of the
sort that you're worried about. What we are trying to do is to think of how
the interfaces and features of LASH could better help support a controller
application's operation. 1.0
Graded saves
Networked audio
User interface standard
Automatic client installation
And I would add to that now:
0.6
Redesign client/server communication
Certificate based security/encryption
Use OSC
Rework API
Genericify patch-system specifics
Provide more useful event system (callbacks, etc)
Rewrite client library in gobject
Rewrite server in C++
Bob
--
Bob Ham <rah(a)bash.sh>