Non-DAW's Session Handling Requirements

Jonathan Moore Liles
May 2008

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.

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:

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