<li><ahref="#n:1.2.6.">1.2.6. Client to Server Control</a>
<li><ahref="#n:1.2.7.">1.2.7. Server Control API</a>
<ul><li><ahref="#n:1.2.7.1.">1.2.7.1. Client to Client Communication</a>
</ul></ul></ul></ul></ul><hr></div>
<h1id="n:1.">1. Non Session Management API</h1>
<p>
The Non Session Management API is used by the various components of the Non audio production suite to allow any number of independent programs to be managed together as part of a logical session (i.e. a song). Thus, operations such as loading and saving are synchronized.
</p>
<p>
The API comprises a simple Open Sound Control (OSC) based protocol, along with some behavioral guidelines, which can easily be implemented by various applications.
</p>
<p>
The Non project contains an program called <tt>nsmd</tt> which is an implementation of the server side of the NSM API. <tt>nsmd</tt> is controlled by the <tt>non-session-manager</tt> GUI. However, the same server-side API can also be implemented by other session managers (such as LADISH), although consistency and robustness will likely suffer if non-NSM compliant clients are allowed to participate in a session. The only dependency for client implementations <tt>liblo</tt> (the OSC library), which several Linux audio applications already link to or plan to link to in the future.
</p>
<p>
The aim of this project is to thoroughly define the behavior required of clients. This is an area where other attempts at session management (LASH and JACK-Session) have failed. Often the difficulty with these systems has been not in implementing support for them, but in attempting to interpret the confusing, ambiguous, or ill-conceived API documentation. For these reasons and more all previous attempts at Linux audio session management protocols are considered harmful.
</p>
<p>
You <b>WILL</b> see some unambiguous and emphatic language in this document. For the good of the user, these rules are meant to be followed and are non-negotiable. If an application does not conform to this specification it should be considered broken. Consistency across applications under session management is very important for a good user experience.
</p>
<h2id="n:1.1.">1.1. Client Behavior Under Session Management</h2>
<p>
Most graphical applications make available to the user a common set of file operations, typically presented under a File or Project menu.
</p>
<p>
These are: New, Open, Save, Save As, Close and Quit or Exit.
The following sub-sections describe how these options should behave when the application is part of an NSM session. These rules only apply when session management is active (that is, after the <tt>announce</tt> handshake described in the <aclass=inthref="#n:1.2.">1.2. NSM OSC Protocol</a> section). In order to provide a consistent and predictable user experience, it is critically important for applications to adhere to these guidelines.
This option may empty/reset the current file or project (possibly after user confirmation). <b>UNDER NO CIRCUMSTANCES</b> should it allow the user to create a new project/file in another location.
The application may, however, elect to implement an option called 'Import into Session', creates a copy of a file/project which is then saved at the session path provided by NSM.
The application may, however, elect to implement an option called 'Export from Session', which creates a copy of the current file/project which is then saved in a user-specified location outside of the session path provided by NSM.
All project specific data created by a client <b>MUST</b> be stored in the per-client storage area provided by NSM. This includes all recorded audio and MIDI files, snapshots, etc. Only global configuration items, exports, and renders of the project may be stored elsewhere (wherever the user specifies).
</p>
<h4id="n:1.1.2.2.">1.1.2.2. External Files</h4>
<p>
Files required by the project but external to it (typically read-only data such as audio samples) <b>SHOULD</b> be referenced by creating a symbolic link within the assigned session area, and then referring to the symlink. This allows sessions to be archived and transported simply (e.g. with "tar -h") by tools that have no knowledge of the project formats of the various clients in the session. The symlinks thus created should, at the very least, be named after the files they refer to (some unique component may be required to prevent collisions)
All message parameters are <b>REQUIRED</b>. All messages <b>MUST</b> be sent from the same socket as the <tt>announce</tt> message, using the <tt>lo_send_from</tt> method of liblo or its equivalent, as the server uses the return addresses to distinguish between clients.
</p>
<p>
Clients <b>MUST</b> create thier OSC servers using the same protocol (UDP,TCP) as found in <tt>NSM_URL</tt>. liblo is lacking a robust TCP implementation at the time of writing, but in the future it may be useful.
</p>
<h3id="n:1.2.1.">1.2.1. Establishing a Connection</h3>
<h4id="n:1.2.1.1.">1.2.1.1. Announce</h4>
<p>
At launch, the client <b>MUST</b> check the environment for the value of <tt>NSM_URL</tt>. If present, the client <b>MUST</b> send the following message to the provided address as soon as it is ready to respond to the <tt>/nsm/client/open</tt> event:
Note that if the application intends to register JACK clients, <tt>application_name</tt><b>MUST</b> be the same as the name that would normally be passed to <tt>jack_client_open</tt>. For example, Non-Mixer sends "Non-Mixer" as its <tt>application_name</tt>. Applications <b>MUST NOT</b> register their JACK clients until receiving an <tt>open</tt> message; the <tt>open</tt> message will provide a unique client name prefix suitable for passing to JACK. This is probably the most complex requirement of the NSM API, but it isn't difficult to implement, especially if the application simply wishes to delay its initialization process breifly while awaiting the <tt>announce</tt> reply and subsequent <tt>open</tt> message.
<tt>capabilities</tt><b>MUST</b> be a string containing a colon separated list of the special capabilities the client possesses. e.g. <tt>:dirty:switch:progress:</tt>
<tt>executable_name</tt><b>MUST</b> be the executable name that the program was launched with. For C programs, this is simply the value of <tt>argv[0]</tt>. Note that hardcoding the name of the program here is not the same as using, as the user may have launched the program from a script with a different name using exec, or have created a symlink to the program. Getting the correct value in scripting languages like Python can be more challenging.
The value of <tt>name_of_session_manager</tt> will depend on the implementation of the NSM server. It might say "Non Session Manager", or it might say "LADISH". This is for display to the user.
</p>
<p>
<tt>capabilities</tt> will be a string containing a colon separated list of special server capabilities.
<tr><td>optional-gui</td><td>server responds to optional-gui messages--if this capability is not present then clients with optional-guis MUST always keep them visible</td></tr>
A client should not consider itself to be under session management until it receives this response. For example, the Non applications activate their "SM" blinkers at this time.
</p>
<p>
If there is an error, a reply of the following form will be sent to the client:
<tr><td>ERR_INCOMPATIBLE_API</td><td>Incompatible API version</td></tr>
<tr><td>ERR_BLACKLISTED</td><td>Client has been blacklisted.</td></tr>
</table></div></center>
<h3id="n:1.2.2.">1.2.2. Server to Client Control Messages</h3>
<p>
Compliant clients <b>MUST</b> accept the client control messages described in this section. All client control messages <b>REQUIRE</b> a response. Responses <b>MUST</b> be delivered back to the sender (NSM) from the same socket used by the client in its <tt>announce</tt> message (by using <tt>lo_send_from</tt>) <b>AFTER</b> the action has been completed or if an error is encountered. The required response is described in the subsection for each message.
If there is an error and the action cannot be completed, then <tt>error_code</tt><b>MUST</b> be set to a valid error code (see <aclass=inthref="#n:1.2.5.">1.2.5. Error Code Definitions</a>) and <tt>message</tt> to a string describing the problem (suitable for display to the user).
The reply can take one of the following two forms, where <tt>path</tt><b>MUST</b> be the path of the message being replied to (e.g. "<i>nsm/client/save"</i>:
There is no message for this. Clients will receive the Unix SIGTERM signal and <b>MUST</b> close cleanly <b>IMMEDIATELY</b>, without displaying any kind of dialog to the user and regardless of whether or not unsaved changes would be lost. When a session is closed the application will receive this signal soon after having responded to a <tt>save</tt> message.
The client may append to the path, creating a sub-directory, e.g. '/song.foo' or simply append the client's native file extension (e.g. '.non' or '.XML'). The same transformation <b>MUST</b> be applied to the name when opening an existing project, as NSM will only provide the instance specific part of the path.
If a project exists at the path, the client <b>MUST</b> immediately open it.
</p>
<p>
If a project does not exist at the path, then the client <b>MUST</b> immediately create and open a new one at the specified path or, for clients which hold all their state in memory, store the path for later use when responding to the <tt>save</tt> message.
</p>
<p>
No file or directory will be created at the specified path by the server. It is up to the client to create what it needs.
</p>
<p>
For clients which <b>HAVE NOT</b> specified the <tt>:switch:</tt> capability, the <tt>open</tt> message will only be delivered once, immediately following the <tt>announce</tt> response.
</p>
<p>
For clients which <b>HAVE</b> specified the <tt>:switch:</tt> capability, the client <b>MUST</b> immediately switch to the specified project or create a new one if it doesn't exist.
</p>
<p>
Clients which are incapable of switching projects or are prone to crashing upon switching <b>MUST NOT</b> include <tt>:switch:</tt> in their capability string.
</p>
<p>
If the user the is allowed to run two or more instances of the application simultaneously (that is to say, there is no technical limitation preventing them from doing so, even if it doesn't make sense to the author), then such an application <b>MUST PRE-PEND</b> the provided <tt>client_id</tt> string to any names it registers with common subsystems (e.g. JACK client names). This ensures that multiple instances of the same application can be restored in any order without scrambling the JACK connections or causing other conflicts. The provided <tt>client_id</tt> will be a concatenation of the value of <tt>application_name</tt> sent by the client in its <tt>announce</tt> message and a unique identifier. Therefore, applications which create single JACK clients can use the value of <tt>client_id</tt> directly as their JACK client name. Applications which register multiple JACK clients (e.g. Non-Mixer) <b>MUST PRE-PEND</b><tt>client_id</tt> value to the client names they register with JACK and the application determined part <b>MUST</b> be unique for that (JACK) client.
</p>
<p>
For example, a suitable JACK client name would be:
Note that this means that the application <b>MUST NOT</b> register with JACK (or any other subsystem requiring unique names) until it receives an <tt>open</tt> message from NSM. Likewise, applications with the <tt>:switch:</tt> capability should close their JACK clients and re-create them with using the new <tt>client_id</tt>. Re-registering is necessary because the JACK API does currently support renaming existing clients, although this is a sorely needed addition.
</p>
<p>
A response is <b>REQUIRED</b> as soon as the open operation has been completed. Ongoing progress may be indicated by sending messages to <tt>/nsm/client/progress</tt>.
</p>
<h5id="n:1.2.2.2.1.">1.2.2.2.1. Response</h5>
<p>
The client <b>MUST</b> respond to the 'open' message with:
This message will only be delivered after a previous <tt>open</tt> message, and may be sent any number of times within the course of a session (including zero, if the user aborts the session).
Accepting this message is optional. The intent is to signal to clients which may have some interdependence (say, peer to peer OSC connections) that the session is fully loaded and all their peers are available. Most clients will not need to act on this message. This message has no meaning when a session is being built or run--only when it is initially loaded. Clients who intend to act on this message <b>MUST</b> not do so by delaying initialization waiting for it.
<h4id="n:1.2.3.2.">1.2.3.2. Show Optional Gui</h4>
<p>
If the client has specified the <tt>optional-gui</tt> capability, then it may receive this message from the server when the user wishes to change the visibility state of the GUI. It doesn't matter if the optional GUI is integrated with the program or if it is a separate program \(as is the case with SooperLooper\). When the GUI is hidden, there should be no window mapped and if the GUI is a separate program, it should be killed.
<h3id="n:1.2.4.">1.2.4. Client to Server Informational Messages</h3>
<p>
These are optional messages which a client can send to the NSM server to inform it about the client's status. The client should not expect any reply to these messages. If a client intends to send a message described in this section, then it <b>MUST</b> add the appropriate value to its <tt>capabilities</tt> string when composing the <tt>announce</tt> message.
If the client has specified the <tt>optional-gui</tt> capability, then it <b>MUST</b> send this message whenever the state of visibility of the optional GUI has changed. It also <b>MUST</b> send this message after it's announce message to indicate the initial visibility state of the optional GUI.
For potentially time-consuming operations, such as <tt>save</tt> and <tt>open</tt>, progress updates may be indicated throughout the duration by sending a floating point value between 0.0 and 1.0, 1.0 indicating completion, to the NSM server.
</p>
<p>
The server will not send a response to these messages, but will relay the information to the user.
</p>
<p>
Note that even when using the <tt>progress</tt> feature, the final response to the <tt>save</tt> or <tt>open</tt> message is still <b>REQUIRED</b>.
</p>
<p>
Clients which intend to send <tt>progress</tt> messages should include <tt>:progress:</tt> in their <tt>announce</tt> capability string.
Some clients may be able to inform the server when they have unsaved changes pending. Such clients may optionally send <tt>is_dirty</tt> and <tt>is_clean</tt> messages.
</p>
<p>
Clients which have this capability should include <tt>:dirty:</tt> in their <tt>announce</tt> capability string.
Clients may send miscellaneous status updates to the server for possible display to the user. This may simply be chatter that is normally written to the console. <tt>priority</tt> should be a number from 0 to 3, 3 being the most important.
</p>
<p>
Clients which have this capability should include <tt>:message:</tt> in their <tt>announce</tt> capability string.
<h3id="n:1.2.6.">1.2.6. Client to Server Control</h3>
<p>
If the server publishes the <tt>:server_control:</tt> capability, then clients can also initiate action by the server. For example, a client might implement a 'Save All' option which sends a <tt>/nsm/server/save</tt> message to the server, rather than requiring the user to switch to the session management interface to effect the save.
</p>
<h3id="n:1.2.7.">1.2.7. Server Control API</h3>
<p>
The session manager not only manages clients via OSC, but it is itself controlled via OSC messages. The server responds to the following messages.
The first parameter of the reply is the path to the message being replied to. The <tt>/error</tt> reply includes an integer error code (non-zero indicates error). <tt>message</tt> will be a description of the error.
If the server includes <tt>:broadcast:</tt> in its capability string, then clients may send broadcast messages to each other through the NSM server. Clients may send messages to the server at the path <tt>/nsm/server/broadcast</tt>.
Would broadcast the following message to all clients in the session (except for the sender), some of which might respond to the message by updating their own tempo maps.
The Non programs use this feature to establish peer to peer OSC communication by symbolic names (client IDs) without having to remember the OSC URLs of peers across sessions.
