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.
>
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) ;-)
>> Additionally, the following would be required in order to fully integrate
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.
>> Non-DAW and Non-Sequencer have the ability to change to a new project/song
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 would also like to see the preferred behavior of new/save/load
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.
>> -+--- Additional Thoughts - - -
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.