new-session-manager/session-manager/doc/MANUAL.mu

! title		Non Session Manager User Manual
! author	Jonathan Moore Liles #(email,male@tuxfamily.org)
! date		February 25, 2012
! extra		#(image,logo,icon.png)

-- Table Of Contents

: User Manual

:: The Non Session Manager Graphical Interface

/ Non Session Manager
< nsm.png

  The Non Session Manager is a graphical interface to the NSM Daemon
  (nsmd). By default, running the command `non-session-manager` will
  start both the GUI and an instance of the daemon. 

  If a different session root than the default is desired, it may be
  specified on the command-line as follows:

> non-session-manager -- --session-root path

  This command will instruct the instance of nsmd that the GUI starts
  to use `path` as the session root.

  All session data is stored in per-session sub-directories of the
  /Session Root/.

::: Session Operations

:::: Open
  
  There are two ways to open a session.

  The first is to click the /Open/ button and type in the exact name
  of an existing session.  The second is to click on the desired
  session name in the session list panel on the left side of the
  interface.

  Either way, opening a session saves the current session and switches
  to the new one. Clients which are capable of switching projects
  without restarting are instructed to do so, resulting in very fast
  session open times when such clients are participating in both
  sessions.

  Clients cannot be added until a session is open, either by /Open/ or
  /New/.

  As each client launches, a status bar representing it will be added
  to the client list on the right half the interface. For clients
  which are capable of reporting their progress, a progress bar will
  also become active.

  Only clients supporting the NSM protocol can be told what to open
  and when to save. Clients not supporting NSM may still be added to
  the session, but their behavior is undefined other than that NSM can
  invoke and kill them.

:::: Close

  This option saves and closes the current session. All clients
  participating in the session are told to quit.  Note that, as
  mentioned in the preceding section, in NSM it is not necessary to
  close one session before opening another.

:::: Abort

  This option closes the current session *without saving*. 

:::: Save

  This option saves the current session, instructing clients
  supporting the NSM protocol to save.

:::: New

  This option saves the current session (if one is open) and creates a
  new one. The user is prompted for a session name. Session names are
  paths under the defined /Session Root/. A session name may include
  any number of hierarchical elements, which need not be pre-existing.

  For example, one might name a session as follows:

> Albums/Magnum Opus/The Best Song Ever Produced

  When inspecting /Session Root/ in a file manager, the above
  represents exactly the path you would see. 

  Renaming a session is not currently supported, but one may simply
  move directories around under /Session Root/ and NSM will detect the
  new layout upon the next invocation. The session name is not stored
  anywhere except in its path.

  Advanced users may choose to use symbolic links to organize their
  sessions. For example, one could store all their songs under
  'Songs\/' and create an 'Albums/\' directory structure which uses
  symlinks to point at the songs stored. 

:::: Duplicate

  Templates are supported in by the Non Session Manager via
  duplication. Clicking on the /Duplicate/ button with a session open
  will prompt the user for a new session name. The daemon will then
  perform a recursive file copy of the session and open the copy. 

  Obviously, this should be avoided for sessions containing audio
  data, as the copy would be very time consuming.

  To create a template in the first place, simply use /New/ to start a
  new session (preferably with a name beginning with "Templates\/"),
  add the desired clients to it, and configure them (e.g. add plugins,
  make JACK connections, etc.)
  
  Now, any time you want to start a session from that template, simply
  switch to the template session and click /Duplicate/ to create a new
  session based on it.

:::: Add Client

  This option will prompt the user for the executable name of the
  client to be added to the session. It is not necessary to type the
  full path (the PATH environment variable will be searched to find
  the executable). 

  When controlling an NSM session distributed across multiple
  machines, the user will also be required to choose which server to
  invoke the client on.

::: Removing a Client From a Session

  If a client dies unexpectedly or is closed by the user (e.g. by
  closing its main window), Non Session Manager will detect this and
  two buttons will appear on that Client's status bar. One button, the
  arrow, causes the client to be restarted and to reopen its project
  file where it left off. The /X/ button causes the client to be
  permanently removed from the session.


:: Saving and Restoring Aspects of the Environment

  NSM manages clients together in a session. That's it. NSM doesn't
  know or care what Window Manager or audio subsystem those clients
  use--nor should it. Specific clients must be written to persist
  these environmental factors, and added to sessions when required.

  For saving and restoring the JACK connection graph, a simple
  headless client named `jackpatch` has been developed and included in
  the NSM distribution. Simply add `jackpatch` do your basic template
  session and all the sessions you base on it will have their JACK
  connection graphs automatically saved and restored.

:: The NSM Daemon

  The NSM Daemon (nsmd) is launched automatically by the Non Session
  Manager interface whenever one is not found to be already running at
  the URL specified in the environment.

  Users who are not attempting to setup advanced modes like shared
  sessions between machines will not normally need to even know that
  `nsmd` is running.

  But for those advanced users, here are the command-line options for launching
  nsmd separately from the GUI.

> nsmd [--session-root path] [--osc-port port] [--detach]

  The `--session-root` option allows one to override where /Session
  Root/ is, from the default of "$HOME\/NSM Sessions" (this option can
  also be passed to the GUI, which will hand it over to the daemon).

  `--osc-port` instructs the daemon to bind to a specific UDP port
  number instead of selecting an available port automatically.

  `--detach` instructs the daemon to close its standard input and
  output and go into the background. This is useful for starting the
  daemon remotely with `rsh`.

  When nsmd starts, it will print a string of the following form its
  standard output.

> NSM_URL=osc.udp://foo.bar.net:17551/

  This is the OSC URL for the daemon process. If this URL is included
  in the environment (by either using a fixed port number or starting
  nsmd early in the initialization process [like in your .xinitrc]
  extracting the URL from its output) then any NSM capable client will
  join the current session when started, even if started from outside
  the Non Session Manager interface (for example, by your Desktop
  Environment's program launch menu).

::: Multiple NSMD Instances

  When dealing with multiple instances of nsmd, whether they be on the
  same host or separate hosts, it is most convenient to use fixed port
  numbers specified with the `--osc-port` command-line option.
  
:::: Distributed Session Management

  In some situations it is necessary to have different audio programs
  running on different machines, connected by S\/PDIF, analog wiring,
  or over TCP\/IP as achieved by `netjack`. Usually the reason for
  doing this is that neither machine is powerful enough to do all the
  DSP or synthesis alone.

  Needless to say, these configurations have historically been
  extremely difficult to manage--requiring heavy scripting and\/or
  lots of manual setup.

  NSM is the first--and currently only--system capable of managing
  these sessions.

  Let us assume the following conditions for our example:

+ We want to distribute a session across two hosts, Host-A and Host-B, on the local area network.
+ Each host has a completely independent file system (i.e. not NFS).
+ We have appropriate access to both hosts.

  The first step is to decide what port numbers to use. Let's choose
  `6661` for Host-A and `6662` for Host-B.

  If either host is running a firewall, then these ports must be opened explicitly!

  To start the daemon on host A:

> user@host-a:~$ nsmd --detach --session-root "$HOME/distributed-nsm-sessions" --osc-port 6661

  To start the daemon on host B (conveniently from host A, via rsh)

> user@host-a:~$ rsh host-b nsmd --detach --session-root "\$HOME/distributed-nsm-sessions" --osc-port 6662

  Note that in the above example, there is a backslash in "$HOME",
  this is because otherwise the variable would be expanded on the
  local machine, giving the local value rather than what we intended.

  Now that both daemons are running, we can start the Non Session
  Manager interface with the following command:

> user@host-a:~$ non-session-manager --nsm-url osc.udp://host-a:6661 --nsm-url osc.udp://host-b:6662

  The Non Session Manager interface will then connect to the daemons
  on both hosts. Creating a new session will create separate session
  files on each host. When adding a client, the interface will present
  the user with a choice of which host to invoke the client on. Aside
  from that it is just like managing any other session. Sessions can
  be opened, saved, switched between, etc. and the desired effect will
  be seen on each host.

:::: Multiple Sessions On One Host

  Simply starting two (or more) instances of the Non Session Manager
  interface on the same machine (when the NSM\_URL environment
  variable is unset) will result in the ability to have two different
  sessions open at the same time on the same host. A lock file
  prevents the two instances from opening the same session.

  Imagining a useful application of this feature is left as an
  exercise for the reader.