malnourite@email-addr-hidden wrote:
> Nedko Arnaudov <nedko@email-addr-hidden> writes:
>> Do you need to know LASH project path or you need to know the directory
>> path where your project data resides? I think there is nothing wrong
>> with providing the later.
>
> Sorry. I should have been more clear. The path to the client-specific
> subdirectory in the current LASH
> project. eg. "~/audio-projects/project-1/The Non-DAW". This path,
> whatever it may be, must be known at all times we are connected to
> LASH. Non-DAW cannot create new captures without this information
> (without risking running out of space, having to move GB of data all
> at once later, etc). Currently, my LASH client implementation relies
> on more or less the same hack that Florian used in his LASH patch for
> Ardour, which is to only use LASH for storing the path to the *real*
> project, but this is undesirable for a number of reasons.
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
do so.
>>> 2. The need to be informed of, or else be able to query at any time,
>>> the LASH project name. If the LASH project path and the LASH project
>>> name weren't different, we could get away with scanning the path for
>>> the name, but this is unfortunately not the case.
>> I dont see anything wrong with this, we can have both query function and
>> signals. In fact we already have some signals to serve in the dbus branch.
+1
[...]
>>> Some of the above are already possible to some extent with the current
>>> API, but complicated greatly by the artificial division of the API into
>>> client and control portions.
>> I think API division is right thing to have. However there should be no
>> artificial restriction of being both regular and control app. AFAIK it
>> is in Juuso's plans to remove this artificial restriction.
It is, and it'll be done by September.
>>> Non-DAW and Non-Sequencer have the ability to change to a new project/song
>>> without restarting, but LASH makes no use of this--always restarting
>>> instances of these programs instead of reusing them. Of course,
>>> Non-DAW and Non-Sequencer have extremely short startup times compared
>>> to other programs in their class, but still, I would like to avoid the
>>> distraction of many windows opening and closing at LASH project change
>>> time--it reflects poorly on my and any other programs which can change
>>> songs without crashing.
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;
}
else
tell it to shut down;
}
>> Maybe crazy idea, but we could have some of lash clients to export dbus
>> object to be controlled without restarting. And to make things even more
>> crazy, this matches my prefered "launch LASH apps only through lashd"
>> scenario. With apps being registered in database. So far we use existing
>> desktop entries infrastructure for launching apps through lashd. We
>> could use autolaunched dbus services too. Juuso, what you think?
>
> This is too complicated. Just restart clients which don't respond with
> a success value to the restore-without-restarting event. Dumb or
> crashy clients will get restarted, smart ones will just change
> projects.
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
>>> operations in all clients specified by LASH so as to avoid confusion
>>> and potential data loss. Should any LASH client be permitted to save
>>> or load to/from disk /it's own state/ without informing LASH? This may
>>> seem harmless when the program state consists of a single file--as it
>>> is assumed that a copy of that file will be saved by the program in the
>>> LASH project directory whenever a LASH save is next performed. But now
>>> the user has two (differing) copies of his file--and he isn't sure which
>>> one he really edited--or where it is on disk. The problem becomes even
>>> more serious when the program state includes a directory filled with
>>> gigabytes of audio sources...
>> I agree. These things need to be documented.
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,
>>> which is supposedly under the control of LASH, as if it was theirs
>>> alone--without informing LASH of their activities? I don't necessarily
>>> know the answer to this question, but I do know that LASH needs to make
>>> a recommendation of some kind regarding the expected behavior--whatever
>>> it may be.
>> IMHO we should give recomendation but I'm against trying to force
>> things. We should the users participate in evolution instead of us
>> trying to enforce things as Gods of Code ;)
>
> I agree. That being said, myself and many others are perfectly willing
> to follow the APIs and recommendations of the libraries we
> use--provided they are clearly and unambiguously stated. Only blind,
> stumbling code can evolve in darkness.
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
>>> asking them to undo/redo and possibly providing feedback), additionally,
>>> we can envision storing state diffs on disk for clients with no native
>>> undo capability--something akin having the state in a git repo could
>>> be used, reloading a reconstruction of prior state upon an 'undo'
>>> request)--this is only viable if LASH can reuse program instances.
>> not that i dislike the idea, but i prefer to defer such functionality
>> for later incarnation of LASH. Unless someone is really motivated to
>> work on this now.
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.
>> For LASH client or for lashd? I personally consider LASH tightly coupled
>> with JACK in the terms of user workflow. Thus I assume lashd and LASH
>> apps interacting directly with JACK. However, with jackdbus approach,
>> only LASH apps have direct dependance of JACK (i.e. are linked against
>> libjack). lashd uses jackdbus instead. LASH control app probably does
>> not interact with JACK server at all. The only possible exception I know
>> so far is to get JACK settings preset from JACK multiconfig object. But
>> I consider that separate module, not directly coupled with JACK itself.
>
> For both. I still firmly believe that JACK (or ALSA or whatever)
> patchbay functionality is not within the proper scope of
> LASH. Approved patchbay clients may be included in the distribution,
> enabled by default, and added to every project; but I don't think that
> any part of LASH proper needs to depend on JACK. Removing this
> dependency would add robustness to the system. As it is now, any time
> JACK dies (not uncommon when you're debugging a connected client under
> GDB), everything goes to hell in a hand-basket.
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
concept.
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... ;)
Juuso
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun May 18 00:15:02 2008
This archive was generated by hypermail 2.1.8 : Sun May 18 2008 - 00:15:02 EEST