Non Session Manager protocol

This option may empty/reset the current file or project (possibly after user confirmation). UNDER NO CIRCUMSTANCES should it allow the user to create a new project/file in another location.

This option MUST be disabled.

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.

This option should behave as normal, saving the current file/project as established by the NSM open message.

UNDER NO CIRCUMSTANCES should this option present the user with a choice of where to save the file.

This option MUST be disabled.

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.

This option MUST be disabled unless its meaning is to disconnect the application from session management.

This option may behave as normal (possibly asking the user to confirm exiting).

All project specific data created by a client MUST 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).

Files required by the project but external to it (typically read-only data such as audio samples) SHOULD 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)

At launch, the client MUST check the environment for the value of NSM_URL. If present, the client MUST send the following message to the provided address as soon as it is ready to respond to the /nsm/client/open event:

If NSM_URL is undefined, invalid, or unreachable, then the client should proceed assuming that session management is unavailable.

api_version_major and api_version_minor must be the two parts of the version number of the NSM API as defined by this document.

Note that if the application intends to register JACK clients, application_name MUST be the same as the name that would normally be passed to jack_client_open. For example, Non-Mixer sends "Non-Mixer" as its application_name. Applications MUST NOT register their JACK clients until receiving an open message; the open 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 announce reply and subsequent open message.

capabilities MUST be a string containing a colon separated list of the special capabilities the client possesses. e.g. :dirty:switch:progress:

executable_name MUST be the executable name that the program was launched with. For C programs, this is simply the value of argv[0]. 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.

There is no message for this. Clients will receive the Unix SIGTERM signal and MUST close cleanly IMMEDIATELY, 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 save message.

path_to_instance_specific_project is a path name assigned to the client for storing its project data.

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 MUST 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 MUST immediately open it.

If a project does not exist at the path, then the client MUST 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 save message.

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.

For clients which HAVE NOT specified the :switch: capability, the open message will only be delivered once, immediately following the announce response.

For clients which HAVE specified the :switch: capability, the client MUST immediately switch to the specified project or create a new one if it doesn’t exist.

Clients which are incapable of switching projects or are prone to crashing upon switching MUST NOT include :switch: in their capability string.

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 MUST PRE-PEND the provided client_id 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 client_id will be a concatenation of the value of application_name sent by the client in its announce message and a unique identifier. Therefore, applications which create single JACK clients can use the value of client_id directly as their JACK client name. Applications which register multiple JACK clients (e.g. Non-Mixer) MUST PRE-PEND client_id value to the client names they register with JACK and the application determined part MUST be unique for that (JACK) client.

For example, a suitable JACK client name would be: $CLIENT_ID/track-1

Note that this means that the application MUST NOT register with JACK (or any other subsystem requiring unique names) until it receives an open message from NSM. Likewise, applications with the :switch: capability should close their JACK clients and re-create them with using the new client_id. Re-registering is necessary because the JACK API does currently support renaming existing clients, although this is a sorely needed addition.

A response is REQUIRED as soon as the open operation has been completed. Ongoing progress may be indicated by sending messages to /nsm/client/progress.

This message will only be delivered after a previous open 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 MUST not do so by delaying initialization waiting for it.

This message does not require a response.

If the client has specified the optional-gui 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.

No response is message is required.

If the client has specified the optional-gui capability, then it MUST send this message whenever the state of visibility of the optional GUI has changed. It also MUST send this message after it’s announce message to indicate the initial visibility state of the optional GUI.

It is the responsibility of the client to remember the visibility state of its GUI across session loads.

No response will be delivered.

For potentially time-consuming operations, such as save and open, 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.

The server will not send a response to these messages, but will relay the information to the user.

Note that even when using the progress feature, the final response to the save or open message is still REQUIRED.

Clients which intend to send progress messages should include :progress: in their announce capability string.

Some clients may be able to inform the server when they have unsaved changes pending. Such clients may optionally send is_dirty and is_clean messages.

Clients which have this capability should include :dirty: in their announce 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. priority should be a number from 0 to 3, 3 being the most important.

Clients which have this capability should include :message: in their announce capability string.