24 Jan
2008
24 Jan
'08
5:28 a.m.
On Thu, 2008-01-24 at 05:33 +0200, Nedko Arnaudov wrote:
I must have been thrown off by Nedko's words "LASH should behave like
all-in-one app" ;-)
From user perspective, yes. lash + patchage like app.
Well, more accurately it would be patchage-like-app + lash + jack + alsa
+ x11 and, if you're going to get networking in on the game, + ssh. You
can see that lash is just a small part of such a system. The key issue
becomes the patchage-like-app.
Bob Ham <rah(a)bash.sh> writes:
> On Wed, 2008-01-23 at 19:44 +0200, Juuso Alasuutari wrote:
>> 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:
>> > On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote:
>> > > Bob Ham <rah(a)bash.sh> writes:
>> > > > More generally, LASH isn't a frontend for JACK.
>> > >
>> > > What about the jack watchdog? What does get killed by it?
>> > 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?
>>
>> I don't think Nedko's proposal is motivated by a desire to work around
>> existing bugs.
>
> It sounded suspiciously to me as though that was exactly what Nedko's
> proposal was :-)
IMHO, jack watchdog is feature, not bug. And yes, LASH
needs a way to
handle it.
Of course it needs to handle it. It needs to cleanly shut down due to
the catastrophic failure. That's very different from creating a layer
betwen JACK and the LASH clients where the catastrophic failure is
glossed over.
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. > 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.
> 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++
Some thoughts regarding your 0.6 wishes:
UDP OSC is one of the evils of current implementation.
Current implementation of what? Regardless, the transport that's used
isn't particularly important; you can just use TCP if UDP is an issue.
Or fix the UDP transport.
certificates? encryption? really? For 0.6? o.0
Overengeneering?
Possibly. However, I think it's a good idea to have it included at the
start of any redesign of the communication system.
I dont think using gobject is good thing in this case,
because of the
KDE/GNOME schism.
Just because the library is written using gobject, doesn't mean clients
have to be. It's now trivial to run a QT main loop and glib main loop
together:
http://developer.kde.org/documentation/tutorials/qtgtk/main.html
I do agree about "Provide more useful event
system (callbacks,
etc)". However, it is important not to break current API, but extend it
or provide alternative API. I also agree with Juuso, that fixing the API
can (and probably will) be made after we fix the more important things.
I think it's important *to* break the current API due to its many
issues. Why do you think that backwards compatibility with the current
API is important?
Bob
--
Bob Ham <rah(a)bash.sh>