[LAD] Non-DAW's Session Handling Requirements

[malnourite at gmail.com]

http://karma.darktech.org/~male/lash_requirements.html

_____________________________

______ __  _     _

-+--- Overview - -    -

The Non-DAW comprises a modular system. It would be convenient for
the author and the users alike if the state of Non-DAW's components
and other, entirely separate, programs could be managed together as a
coherent whole.  The LASH system appears, at first glance, to support this
kind of arrangement.  However, the current LASH API is overly complex and
lacking in what this author considers to be a basic level of functional
maturity. It is this confusion, I believe, which has resulted in the
poor adoption of LASH and its subsequent stagnation.

______ __  _     _

-+--- Basic Concerns - -    -

Non-DAW, and other complex programs with large state which cannot
be held in RAM all at once, require a few things that LASH doesn't
currently provide.  These needs include the following:

  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.

  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.


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.

  2. Ability to save the current project as a template.

  3. Ability to initiate a save of the entire LASH project.

  4. Ability to choose from a list of LASH projects to load.


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.

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.

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...

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.

______ __  _     _

-+--- 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.

  * 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.

  * 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.

  * Looser integration with/no direct dependance on JACK.


Some of these have been mentioned before and I've omitted many potential
improvements and design changes which I consider less important.

-- 
May 15 2008,
John Moore Liles