I agree that a client should by default be able to trust its path to
remain unaltered. If the LASH server wants to change it (i.e. move its
contents to another location), it should ask the client for a chance to
>>> 2. The need to be informed of, or else be able to query at any time,
It is, and it'll be done by September.
>>> Non-DAW and Non-Sequencer have the ability to change to a new project/song
This is a feature worth pursuing, IMHO. It would also seem like a fairly
trivial thing to do:
cleanup old project, but don't ditch clients;
iterate old project's client list;
if client is part of new project
change its ID;
tell it some other attributes from the new project it needs to know;
tell it to load its data from the new project;
tell it to shut down;
>> Maybe crazy idea, but we could have some of lash clients to export dbus
If we're to implement this feature, it shouldn't require too much from a
client. A generic "close old && load new" sequence, available in most
applications' File menus, should just about do it. A client should be
able to handle simple LASH requests like this.
I'm not for making clients into named D-Bus services. I contemplated
this at one point, but it's IMHO not worth the hassle. First of all,
you're not allowed to run more than one instance of a named service at a
time. Even to get past that restriction would be a pain.
>>> I would also like to see the preferred behavior of new/save/load
Yes, obviously we haven't a consensus about these issues. We need to
have a look at the pros and cons when the time is ripe.
>>> Is it really advisable for LASH clients to operate on their state,
I might favor dictating clients to not operate on their own state, but
I'm not opposed to the recommend-and-enlighten approach either.
>>> * Global Undo/Redo functionality (simply sends a message to all clients
Some undo/redo mechanism might be plausible, but state diffs sounds
almost too ambitious IMHO.
One feature I've had in mind is TryQuit, meaning that could might send a
"quit now if you haven't got unsaved data" request to clients. Those
clients which do have unsaved data would not quit, but would instead
send a reply back to lashd.
But it could pose a problem if some clients would quit (because they
have no unsaved data), and those that don't quit would be unable to
correctly save because some clients have quit. So maybe it would be
better to just add a method for querying clients if they have unsaved
data. Lashd could then either quit all clients at once, or ask the
clients to save first if one or more has unsaved data.
>>> * Looser integration with/no direct dependance on JACK.
This is the only part of your original post which I don't mostly agree
with. I can understand the arguments against coupling JACK and LASH, but
the way I see it is that we're basically all working for a common
JACK-ified desktop in the end. LASH and JACK complement eachother IMHO,
and I believe that the patchbay functionality does belong in LASH by
And I would like to point out that currently lashd ('dbus' branch) no
longer goes down if JACK happens to. My recent work on separating LASH
from libjack and converting it to use the D-Bus interface has paid off.
You can kick JACK as hard as you like, LASH will stay put... as long as
you don't run into the numerous bugs I've willingly planted into LASH in
anticipation of lucrative support contracts... ;)
Linux-audio-dev mailing list