17 May
2008
17 May
'08
10:50 a.m.
Nedko Arnaudov <nedko(a)arnaudov.name> writes:
Normally the name of a Non-DAW project is extracted from the final
component of its path. This makes it trivial to move projects around,
renaming them--without having to hand-edit several different files
with a name embedded. When connected to LASH, however, it is more
likely that the user will use the LASH renaming facility. Keeping the
names displayed by various LASH clients in a session is, I think,
important for usability. But in order for Non-DAW to display the LASH
project name, it has to know it first (at project open/change time,
and also whenever a rename event occurs) ;-)
I think of it more as the current 'client' API being a very small
subset of the (unimplemented) full API, usable mainly by simple
programs lacking user interfaces.
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.
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.
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.
--
May 17 2008
John Moore Liles
malnourite(a)gmail.com writes:
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.
1. The need to know the LASH project path the
moment it first joins the
LASH session at startup. If this were so it could start a new Non-DAW
project under the LASH project path and new captures would go in their
right place without any intervention by the user. To clarify: there
must be no time when Non-DAW is connected to LASH without knowledge
of the path to the current LASH project directory.
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. 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. Additionally,
the following would be required in order to fully integrate
with LASH (transparently to the user).
1. Ability to initiate new projects, choosing among a list of previously
recorded templates.
planned already
2. Ability to save the current project as a
template.
planned already
3. Ability to initiate a save of the entire
LASH project.
even non-dbus implementation has this AFAIK
4. Ability to choose from a list of LASH
projects to load.
already working. In dbus branch we have GetProjects method instead of
reading audio projects directory on client side.
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. 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.
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? 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.
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 ;) -+---
Additional Thoughts - - -
There are also many things which LASH /could/ do to enhance the
integration experience, but doesn't.
These include, but are by no means limited to, the following:
* Templating and layering functionality.
already planned
* Project grouping (eg. all songs for an album)
for easy management
of hundreds of projects. Please use subdirectories and/or symlinks
for this and not some XML junk.
already planned
* 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.
* 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.