diff --git a/lib/ntk b/lib/ntk
deleted file mode 160000
index dae1771..0000000
--- a/lib/ntk
+++ /dev/null
@@ -1 +0,0 @@
-Subproject commit dae177189b12f74ea01ac2389b76326c06d9be78
diff --git a/session-manager/doc/API.html b/session-manager/doc/API.html
deleted file mode 100644
index 66188b0..0000000
--- a/session-manager/doc/API.html
+++ /dev/null
@@ -1,615 +0,0 @@
-
-
-
-
-
1. Non Session Management API
-
-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.
-
-
-The API comprises a simple Open Sound Control (OSC) based protocol, along with some behavioral guidelines, which can easily be implemented by various applications.
-
-
-The Non project contains an program called nsmd which is an implementation of the server side of the NSM API. nsmd is controlled by the non-session-manager 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 liblo (the OSC library), which several Linux audio applications already link to or plan to link to in the future.
-
-
-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.
-
-
-You WILL 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.
-
-
1.1. Client Behavior Under Session Management
-
-Most graphical applications make available to the user a common set of file operations, typically presented under a File or Project menu.
-
-
-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 announce handshake described in the 1.2. NSM OSC Protocol section). In order to provide a consistent and predictable user experience, it is critically important for applications to adhere to these guidelines.
-
-
1.1.1. File Menu
-
1.1.1.1. New
-
-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.
-
-
1.1.1.2. Open
-
-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.
-
-
1.1.1.3. Save
-
-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.
-
-
1.1.1.4. Save As
-
-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.
-
-
1.1.1.5. Close (as distinguished from Quit or Exit)
-
- This option MUST be disabled unless its meaning is to disconnect the application from session management.
-
-
1.1.1.6. Quit or Exit
-
-This option may behave as normal (possibly asking the user to confirm exiting).
-
-
1.1.2. Data Storage
-
1.1.2.1. Internal Files
-
-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).
-
-
1.1.2.2. External Files
-
-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)
-
-
-samples/drumbeat-1.wav
-samples/drumbeat-2.wav
- |
-
-
1.2. NSM OSC Protocol
-
-All message parameters are REQUIRED. All messages MUST be sent from the same socket as the announce message, using the lo_send_from method of liblo or its equivalent, as the server uses the return addresses to distinguish between clients.
-
-
-Clients MUST create thier OSC servers using the same protocol (UDP,TCP) as found in NSM_URL. liblo is lacking a robust TCP implementation at the time of writing, but in the future it may be useful.
-
-
1.2.1. Establishing a Connection
-
1.2.1.1. Announce
-
-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:
-
-
-/nsm/server/announce s:application_name s:capabilities s:executable_name i:api_version_major i:api_version_minor i:pid
- |
-
-
-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.
-
-
-
-Fig. 1.1. Available Client Capabilities
-
-Name | Description |
-switch | client is capable of responding to multiple `open` messages without restarting |
-dirty | client knows when it has unsaved changes |
-progress | client can send progress updates during time-consuming operations |
-message | client can send textual status updates |
-optional-gui | client has an optional GUI |
-
-
1.2.1.2. Response
-
-The server will respond to the client's announce message with the following message:
-
-
-/reply "/nsm/server/announce" s:message s:name_of_session_manager s:capabilities
- |
-
-
-message is a welcome message.
-
-
-The value of name_of_session_manager 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.
-
-
-capabilities will be a string containing a colon separated list of special server capabilities.
-
-
-Presently, the server capabilities are:
-
-
-
-Fig. 1.2. Available Server Capabilities
-
-Name | Description |
-server-control | client-to-server control |
-broadcast | server responds to /nsm/server/broadcast message |
-optional-gui | server responds to optional-gui messages--if this capability is not present then clients with optional-guis MUST always keep them visible |
-
-
-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.
-
-
-If there is an error, a reply of the following form will be sent to the client:
-
-
-/error "/nsm/server/announce" i:error_code s:error_message
- |
-
-
-The following table defines possible values of error_code:
-
-
-
-Fig. 1.3. Response codes
-
-Code | Meaning |
-ERR_GENERAL | General Error |
-ERR_INCOMPATIBLE_API | Incompatible API version |
-ERR_BLACKLISTED | Client has been blacklisted. |
-
-
1.2.2. Server to Client Control Messages
-
-Compliant clients MUST accept the client control messages described in this section. All client control messages REQUIRE a response. Responses MUST be delivered back to the sender (NSM) from the same socket used by the client in its announce message (by using lo_send_from) AFTER 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 error_code MUST be set to a valid error code (see 1.2.5. Error Code Definitions) and message to a string describing the problem (suitable for display to the user).
-
-
-The reply can take one of the following two forms, where path MUST be the path of the message being replied to (e.g. "nsm/client/save":
-
-
-/reply s:path s:message
- |
-
-
-/error s:path i:error_code s:message
- |
-
-
1.2.2.1. Quit
-
-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.
-
-
1.2.2.2. Open
-
-/nsm/client/open s:path_to_instance_specific_project s:display_name s:client_id
- |
-
-
-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:
-
-
-
-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.
-
-
1.2.2.2.1. Response
-
-The client MUST respond to the 'open' message with:
-
-
-/reply "/nsm/client/open" s:message
- |
-
-
-Or
-
-
-/error "/nsm/client/open" i:error_code s:message
- |
-
-
-
-Fig. 1.4. Response Codes
-
-Code | Meaning |
-ERR | General Error |
-ERR_BAD_PROJECT | An existing project file was found to be corrupt |
-ERR_CREATE_FAILED | A new project could not be created |
-ERR_UNSAVED_CHANGES | Unsaved changes would be lost |
-ERR_NOT_NOW | Operation cannot be completed at this time |
-
-
1.2.2.3. Save
-
-
-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).
-
-
-
1.2.2.3.1. Response
-
-The client MUST respond to the 'save' message with:
-
-
-/reply "/nsm/client/save" s:message
- |
-
-
-Or
-
-
-/error "/nsm/client/save" i:error_code s:message
- |
-
-
-
-Fig. 1.5. Response Codes
-
-Code | Meaning |
-ERR | General Error |
-ERR_SAVE_FAILED | Project could not be saved |
-ERR_NOT_NOW | Operation cannot be completed at this time |
-
-
1.2.3. Server to Client Informational Messages
-
1.2.3.1. Session is Loaded
-
- 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.
-
-
-/nsm/client/session_is_loaded
- |
-
-
-This message does not require a response.
-
-
1.2.3.2. Show Optional Gui
-
-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.
-
-
-/nsm/client/show_optional_gui
- |
-
-
-/nsm/client/hide_optional_gui
- |
-
-
-No response is message is required.
-
-
1.2.4. Client to Server Informational Messages
-
-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 MUST add the appropriate value to its capabilities string when composing the announce message.
-
-
1.2.4.1. Optional GUI
-
-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.
-
-
-/nsm/client/gui_is_hidden
- |
-
-
-/nsm/client/gui_is_shown
- |
-
-
-No response will be delivered.
-
-
1.2.4.2. Progress
-
-/nsm/client/progress f:progress
- |
-
-
-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.
-
-
1.2.4.3. Dirtiness
-
-/nsm/client/is_dirty
- |
-
-
-/nsm/client/is_clean
- |
-
-
-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.
-
-
1.2.4.4. Status Messages
-
-/nsm/client/message i:priority s:message
- |
-
-
-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.
-
-
1.2.5. Error Code Definitions
-
-
-Fig. 1.6. Error Code Definitions
-
-Symbolic Name | Integer Value |
-ERR_GENERAL | -1 |
-ERR_INCOMPATIBLE_API | -2 |
-ERR_BLACKLISTED | -3 |
-ERR_LAUNCH_FAILED | -4 |
-ERR_NO_SUCH_FILE | -5 |
-ERR_NO_SESSION_OPEN | -6 |
-ERR_UNSAVED_CHANGES | -7 |
-ERR_NOT_NOW | -8 |
-ERR_BAD_PROJECT | -9 |
-ERR_CREATE_FAILED | -10 |
-
-
1.2.6. Client to Server Control
-
-If the server publishes the :server-control: capability, then clients can also initiate action by the server. For example, a client might implement a 'Save All' option which sends a /nsm/server/save message to the server, rather than requiring the user to switch to the session management interface to effect the save.
-
-
1.2.7. Server Control API
-
-The session manager not only manages clients via OSC, but it is itself controlled via OSC messages. The server responds to the following messages.
-
-
-All of the following messages will be responded to, at the sender's address, with one of the two following messages:
-
-
-/reply s:path s:message
- |
-
-
-/error s:path i:error_code s:message
- |
-
-
- The first parameter of the reply is the path to the message being replied to. The /error reply includes an integer error code (non-zero indicates error). message will be a description of the error.
-
-
-The possible errors are:
-
-
-
-Fig. 1.7. Responses
-
-Code | Meaning |
-ERR_GENERAL | General Error |
-ERR_LAUNCH_FAILED | Launch failed |
-ERR_NO_SUCH_FILE | No such file |
-ERR_NO_SESSION | No session is open |
-ERR_UNSAVED_CHANGES | Unsaved changes would be lost |
-
-
-- /nsm/server/add s:executable_name
-
-
-Adds a client to the current session.
-
-
-- /nsm/server/save
-
-
-Saves the current session.
-
-
-- /nsm/server/open s:project_name
-
-
-Saves the current session and loads a new session.
-
-
-- /nsm/server/new s:project_name
-
-
-Saves the current session and creates a new session.
-
-
-- /nsm/server/duplicate s:new_project
-
-
-Saves and closes the current session, makes a copy, and opens it.
-
-
-- /nsm/server/close
-
-
-Saves and closes the current session.
-
-
-- /nsm/server/abort
-
-
-Closes the current session WITHOUT SAVING
-
-
-- /nsm/server/quit
-
-
-Saves and closes the current session and terminates the server.
-
-
-- /nsm/server/list
-
-
-Lists available projects. One /reply message will be sent for each existing project.
-
-
1.2.7.1. Client to Client Communication
-
-If the server includes :broadcast: 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 /nsm/server/broadcast.
-
-
-The format of this message is as follows:
-
-
-/nsm/server/broadcast s:path [arguments...]
- |
-
-
-The message will then be relayed to all clients in the session at the path path (with the arguments shifted by one).
-
-
-For example the message:
-
-
-/nsm/server/broadcast /tempomap/update "0,120,4/4:12351234,240,4/4"
- |
-
-
-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.
-
-
-/tempomap/update "0,120,4/4:12351234,240,4/4"
- |
-
-
-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.
-
-
-
-
diff --git a/session-manager/doc/API.mu b/session-manager/doc/API.mu
deleted file mode 100644
index 2ee3475..0000000
--- a/session-manager/doc/API.mu
+++ /dev/null
@@ -1,611 +0,0 @@
-
-! title Non Session Management API
-! author Jonathan Moore Liles #(email,male@tuxfamily.org)
-! revision Version 1.2
-! extra #(image,logo,icon.png)
-
--- Table Of Contents
-
-: Non Session Management API
-
- 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.
-
- The API comprises a simple Open Sound Control (OSC) based protocol,
- along with some behavioral guidelines, which can easily be
- implemented by various applications.
-
- The Non project contains an program called `nsmd` which is an
- implementation of the server side of the NSM API. `nsmd` is
- controlled by the `non-session-manager` 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 `liblo` (the OSC
- library), which several Linux audio applications already link to or
- plan to link to in the future.
-
- 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.
-
- You *WILL* 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.
-
-:: Client Behavior Under Session Management
-
- Most graphical applications make available to the user a common set
- of file operations, typically presented under a File or Project
- menu.
-
- 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 `announce`
- handshake described in the #(ref,Non Session Management API::NSM OSC Protocol) section).
-
- In order to provide a consistent and predictable user experience, it
- is critically important for applications to adhere to these
- guidelines.
-
-::: File Menu
-
-:::: New
-
- 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.
-
-:::: Open
-
- 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.
-
-:::: Save
-
- 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.
-
-:::: Save As
-
- 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.
-
-:::: Close (as distinguished from Quit or Exit)
-
- This option *MUST* be disabled unless its meaning is to disconnect
- the application from session management.
-
-:::: Quit or Exit
-
- This option may behave as normal (possibly asking the user to
- confirm exiting).
-
-::: Data Storage
-
-:::: Internal Files
-
- 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).
-
-:::: External Files
-
- 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)
-
-> samples/drumbeat-1.wav
-> samples/drumbeat-2.wav
-
-:: NSM OSC Protocol
-
- All message parameters are *REQUIRED*. All messages *MUST* be sent
- from the same socket as the `announce` message, using the
- `lo\_send\_from` method of liblo or its equivalent, as the server uses
- the return addresses to distinguish between clients.
-
- Clients *MUST* create thier OSC servers using the same protocol
- (UDP,TCP) as found in `NSM\_URL`. liblo is lacking a robust TCP
- implementation at the time of writing, but in the future it may be
- useful.
-
-::: Establishing a Connection
-
-:::: Announce
-
- 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:
-
-> /nsm/server/announce s:application_name s:capabilities s:executable_name i:api_version_major i:api_version_minor i:pid
-
- 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.
-
-// Available Client Capabilities
-[[ Name, Description
-[[ switch, client is capable of responding to multiple `open` messages without restarting
-[[ dirty, client knows when it has unsaved changes
-[[ progress, client can send progress updates during time-consuming operations
-[[ message, client can send textual status updates
-[[ optional-gui, client has an optional GUI
-
-:::: Response
-
- The server will respond to the client's `announce` message with the
- following message:
-
-> /reply "/nsm/server/announce" s:message s:name_of_session_manager s:capabilities
-
- `message` is a welcome message.
-
- The value of `name\_of\_session\_manager` 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.
-
- `capabilities` will be a string containing a colon separated list of
- special server capabilities.
-
- Presently, the server `capabilities` are:
-
-// Available Server Capabilities
-[[ Name, Description
-[[ server-control, client-to-server control
-[[ broadcast, server responds to /nsm/server/broadcast message
-[[ optional-gui, server responds to optional-gui messages--if this capability is not present then clients with optional-guis MUST always keep them visible
-
- 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.
-
- If there is an error, a reply of the following form will be sent to
- the client:
-
-> /error "/nsm/server/announce" i:error_code s:error_message
-
- The following table defines possible values of `error\_code`:
-
-// Response codes
-[[ Code, Meaning
-[[ ERR_GENERAL, General Error
-[[ ERR_INCOMPATIBLE_API, Incompatible API version
-[[ ERR_BLACKLISTED, Client has been blacklisted.
-
-::: Server to Client Control Messages
-
- Compliant clients *MUST* accept the client control messages
- described in this section. All client control messages *REQUIRE* a
- response. Responses *MUST* be delivered back to the sender (NSM)
- from the same socket used by the client in its `announce` message
- (by using `lo\_send\_from`) *AFTER* 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
- `error\_code` *MUST* be set to a valid error code (see #(ref,Non Session Management API::NSM OSC Protocol::Error Code Definitions))
- and `message` to a string describing the problem (suitable
- for display to the user).
-
- The reply can take one of the following two forms, where `path` *MUST* be
- the path of the message being replied to (e.g. "/nsm\/client\/save"):
-
-> /reply s:path s:message
-
-> /error s:path i:error_code s:message
-
-:::: Quit
-
- 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.
-
-:::: Open
-
-> /nsm/client/open s:path_to_instance_specific_project s:display_name s:client_id
-
- `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`.
-
-::::: Response
-
- The client *MUST* respond to the 'open' message with:
-
-> /reply "/nsm/client/open" s:message
-
- Or
-
-> /error "/nsm/client/open" i:error_code s:message
-
-// Response Codes
-[[ Code, Meaning
-[[ ERR, General Error
-[[ ERR_BAD_PROJECT, An existing project file was found to be corrupt
-[[ ERR_CREATE_FAILED, A new project could not be created
-[[ ERR_UNSAVED_CHANGES, Unsaved changes would be lost
-[[ ERR_NOT_NOW, Operation cannot be completed at this time
-
-:::: Save
-
-> /nsm/client/save
-
- 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).
-
- If able to, the client *MUST* immediately save the current
- application specific project data to the project path previously
- established in the 'open' message. *UNDER NO CIRCUMSTANCES* should a
- dialog be displayed to the user (giving a choice of where to save,
- etc.)
-
- However, if the client is incapable of saving at the specific moment
- without disturbing the user (e.g. a JACK client that can't save
- while the transport is rolling without causing massive XRUNS), then
- the client may respond to "/error" with ERR_NOT_NOW and a string
- explaining exactly why the save could not be completed (so that, in
- this example, the user knows that they have to stop the transport in
- order to save).
-
-::::: Response
-
- The client *MUST* respond to the 'save' message with:
-
-> /reply "/nsm/client/save" s:message
-
- Or
-
-> /error "/nsm/client/save" i:error_code s:message
-
-// Response Codes
-[[ Code, Meaning
-[[ ERR, General Error
-[[ ERR_SAVE_FAILED, Project could not be saved
-[[ ERR_NOT_NOW, Operation cannot be completed at this time
-
-::: Server to Client Informational Messages
-
-:::: Session is Loaded
-
- 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.
-
-> /nsm/client/session_is_loaded
-
- This message does not require a response.
-
-:::: Show Optional Gui
-
- 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.
-
-> /nsm/client/show_optional_gui
-
-> /nsm/client/hide_optional_gui
-
- No response is message is required.
-
-::: Client to Server Informational Messages
-
- 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 *MUST* add the
- appropriate value to its `capabilities` string when composing the
- `announce` message.
-
-:::: Optional GUI
-
- 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.
-
-> /nsm/client/gui_is_hidden
-
-> /nsm/client/gui_is_shown
-
- No response will be delivered.
-
-:::: Progress
-
-> /nsm/client/progress f:progress
-
- 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.
-
-:::: Dirtiness
-
-> /nsm/client/is_dirty
-
-> /nsm/client/is_clean
-
- 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.
-
-:::: Status Messages
-
-> /nsm/client/message i:priority s:message
-
- 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.
-
-::: Error Code Definitions
-
-// Error Code Definitions
-[[ Symbolic Name, Integer Value
-[[ ERR_GENERAL, -1
-[[ ERR_INCOMPATIBLE_API, -2
-[[ ERR_BLACKLISTED, -3
-[[ ERR_LAUNCH_FAILED, -4
-[[ ERR_NO_SUCH_FILE, -5
-[[ ERR_NO_SESSION_OPEN, -6
-[[ ERR_UNSAVED_CHANGES, -7
-[[ ERR_NOT_NOW, -8
-[[ ERR_BAD_PROJECT, -9
-[[ ERR_CREATE_FAILED, -10
-
-::: Client to Server Control
-
- If the server publishes the `:server-control:` capability, then
- clients can also initiate action by the server. For example, a
- client might implement a 'Save All' option which sends a
- `\/nsm\/server\/save` message to the server, rather than requiring
- the user to switch to the session management interface to effect the
- save.
-
-::: Server Control API
-
- The session manager not only manages clients via OSC, but it is
- itself controlled via OSC messages. The server responds to the
- following messages.
-
- All of the following messages will be responded to, at the sender's
- address, with one of the two following messages:
-
-> /reply s:path s:message
-
-> /error s:path i:error_code s:message
-
- The first parameter of the reply is the path to the message being
- replied to. The `\/error` reply includes an integer error code
- (non-zero indicates error). `message` will be a description of the
- error.
-
- The possible errors are:
-
-// Responses
-[[ Code, Meaning
-[[ ERR_GENERAL, General Error
-[[ ERR_LAUNCH_FAILED, Launch failed
-[[ ERR_NO_SUCH_FILE, No such file
-[[ ERR_NO_SESSION, No session is open
-[[ ERR_UNSAVED_CHANGES, Unsaved changes would be lost
-
-= /nsm/server/add s:executable_name
-
- Adds a client to the current session.
-
-= /nsm/server/save
-
- Saves the current session.
-
-= /nsm/server/open s:project_name
-
- Saves the current session and loads a new session.
-
-= /nsm/server/new s:project_name
-
- Saves the current session and creates a new session.
-
-= /nsm/server/duplicate s:new_project
-
- Saves and closes the current session, makes a copy, and opens it.
-
-= /nsm/server/close
-
- Saves and closes the current session.
-
-= /nsm/server/abort
-
- Closes the current session *WITHOUT SAVING*
-
-= /nsm/server/quit
-
- Saves and closes the current session and terminates the server.
-
-= /nsm/server/list
-
- Lists available projects. One `\/reply` message will be sent for each existing project.
-
-:::: Client to Client Communication
-
- If the server includes `:broadcast:` 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
- `\/nsm\/server\/broadcast`.
-
- The format of this message is as follows:
-
-> /nsm/server/broadcast s:path [arguments...]
-
- The message will then be relayed to all clients in the session at
- the path `path` (with the arguments shifted by one).
-
- For example the message:
-
-> /nsm/server/broadcast /tempomap/update "0,120,4/4:12351234,240,4/4"
-
- 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.
-
-> /tempomap/update "0,120,4/4:12351234,240,4/4"
-
- 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.
diff --git a/session-manager/doc/MANUAL.html b/session-manager/doc/MANUAL.html
deleted file mode 100644
index 4c66890..0000000
--- a/session-manager/doc/MANUAL.html
+++ /dev/null
@@ -1,265 +0,0 @@
-
-
-
-
-
1. User Manual
-
1.1. The Non Session Manager Graphical Interface
-
-
-Fig. 1.1. Non Session Manager
-
-
- |
-
-
-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.
-
-
1.1.1. Session Operations
-
1.1.1.1. 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.
-
-
1.1.1.2. 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.
-
-
1.1.1.3. Abort
-
-This option closes the current session without saving.
-
-
1.1.1.4. Save
-
-This option saves the current session, instructing clients supporting the NSM protocol to save.
-
-
1.1.1.5. 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.
-
-
-
1.1.1.6. 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.
-
-
1.1.1.7. 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.
-
-
1.1.2. 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.
-
-
1.2. 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.
-
-
1.3. 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).
-
-
1.3.1. 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.
-
-
1.3.1.1. 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.
-
-
1.3.1.2. 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.
-
-
Distribution
-
-Development of the Non Session Manager can be followed with Git:
-
-
-git clone git://git.tuxfamily.org/gitroot/non/non.git
- |
-
-
-There are no pre-compiled binaries available.
-
-
-
-
diff --git a/session-manager/doc/MANUAL.mu b/session-manager/doc/MANUAL.mu
deleted file mode 100644
index e4c2990..0000000
--- a/session-manager/doc/MANUAL.mu
+++ /dev/null
@@ -1,266 +0,0 @@
-
-! title Non Session Manager User Manual
-! author Jonathan Moore Liles #(email,male@tuxfamily.org)
-! 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.
-
-; Distribution
-
- Development of the Non Session Manager can be followed with Git:
-
-> git clone git://git.tuxfamily.org/gitroot/non/non.git
-
- There are no pre-compiled binaries available.
diff --git a/session-manager/doc/Makefile b/session-manager/doc/Makefile
deleted file mode 100644
index d2ed882..0000000
--- a/session-manager/doc/Makefile
+++ /dev/null
@@ -1,25 +0,0 @@
-
-SRCS=$(wildcard *.mu)
-
-OBJS=$(SRCS:.mu=.html)
-
-%.html: %.mu
- @ echo Mupping $<...
- @ mup.wrapper html $<
-
-.PHONY: all clean
-
-all: $(OBJS)
-
-upload: all
- @ ln -sf MANUAL.html index.html
- @ rsync -L mup.css MANUAL.html API.html index.html *.png ssh.tuxfamily.org:/home/non/non.tuxfamily.org-web/htdocs/nsm
- @ rm -f index.html
-
-install:
- @ install -d "$(DESTDIR)$(DOCUMENT_PATH)"/non-session-manager
- @ cp $(OBJS) *.png mup.css ../../COPYING "$(DESTDIR)$(DOCUMENT_PATH)"/non-session-manager
-# @ ln -sf $(PIXMAP_PATH)/logo.png $(DOCUMENT_PATH)
-
-clean:
- rm -f $(OBJS)
diff --git a/session-manager/doc/icon.png b/session-manager/doc/icon.png
deleted file mode 120000
index 1ad72bf..0000000
--- a/session-manager/doc/icon.png
+++ /dev/null
@@ -1 +0,0 @@
-../icons/hicolor/256x256/apps/non-session-manager.png
\ No newline at end of file
diff --git a/session-manager/doc/mup.css b/session-manager/doc/mup.css
deleted file mode 100644
index 10aceae..0000000
--- a/session-manager/doc/mup.css
+++ /dev/null
@@ -1,461 +0,0 @@
-
-/* Example CSS Style for MUP */
-
-body
-{
- font: normal normal 14pt "Helvetica", sans-serif;
-/* background: url("http://non.tuxfamily.org/background-pattern.png") fixed; */
- background-color: #121212; color: lightgray; padding: 0; margin: 0;
-}
-
-a:link {
- color: white;
-}
-a:visited {
- color: olive;
-}
-a:active {
- color: white;
-}
-a:link:hover {
- text-decoration: underline;
-}
-
-/* #(url) */
-a.ext:link {
- color: red;
- text-decoration: none;
- border-bottom: dashed silver 1;
-}
-a.ext:visited {
- color: darkred;
- border-bottom: dashed silver 1;
- text-decoration: none;
-}
-
-/* #(ref) */
-a.int:link {
- border-bottom: dashed silver 0.15em;
-}
-a.int:link:hover {
- text-decoration: none;
- color: white;
-}
-
-/*
- a[href^="#"]:link {
- border-bottom: dashed silver 0.15em;
- }
- a[href^="#"]:link:hover {
- text-decoration: none;
- color: white;
- }
- */
-
-p:contains("Warning:") {
- background: #d00;
- color: white;
- border: dotted gray 0.5em;
- display: block;
-}
-
-/* First letter of first paragraph of every chapter */
-/*
- h1 + p:first-letter {
- text-transform: uppercase;
- float: left;
- line-height: 0.8em;
- font-size: 350%;
- font-family: Serif;
- letter-spacing: 0;
- margin-right: 0.1em;
- margin-top: 0.1em;
- border: solid gray 1px;
- padding: 1px;
- color: #d00;
- text-shadow: #666 3px 3px 3px;
- }
- */
-/* First paragraph of every chapter */
-/*
- h1 + p {
- text-indent: 0;
- }
- */
-
-/* cover */
-#cover * {
- background: transparent;
-}
-#cover {
- position: relative;
-/* background: #da0;*/
- background: #555;
- color: #aaa;
- text-align: center;
- margin: 0;
- padding: 0.5em;
- border-top: 4px solid black;
- border-bottom: 4px solid black;
-}
-#cover h1, #cover h3 {
- text-shadow: #222 0.2em 0.2em 0.2em;
- color: white;
- border: none;
- letter-spacing: 0.2em;
- line-height: 0.8em;
- margin-left: 2em;
- margin-right: 2em;
-}
-#cover h1:before, #cover h1:after {
-/* content: "::"; */
- font-size: 300%;
- color: black;
-}
-#cover h1:before {
- position: absolute;
- top: 0.2em;
- left: 0.1em;
-}
-#cover h1:after {
- position: absolute;
- top: 0.2em;
- right: 0.1em;
-}
-#cover hr {
- display: none;
-}
-
-hr:first-child {
- display: none;
-}
-
-hr {
- height: 0.2em;
- background: #555;
- color: #555;
- margin-left: 0.5em;
-}
-
-#cover a:visited {
- color: black;
-}
-
-/* endnote */
-#endnote {
- color: black;
-}
-
-/* TOC */
-#toc {
- position: relative;
-}
-#toc hr {
-}
-#toc h1 {
-}
-#toc ul {
- font-size: 125%;
- font-weight: bold;
- margin-bottom: 1em;
-}
-#toc ul ul {
- font-size: 90%;
- font-weight: normal;
- margin-bottom: 0;
-}
-#toc li {
- list-style: none;
-
-}
-#toc a:link {
- border-bottom: 0;
-}
-
-/* */
-#body {
- position: relative;
- margin: 0 auto;
- padding: 0.5em;
- max-width: 900px;
- background-color: #1c1c1c;
-}
-/* ;, : */
-h1 {
- color: #fff;
- border-bottom: solid #444 0.1em;
- text-shadow: 1px 1px 2px #000;
-
-}
-/* ::, :::, ::::, :::::, :::::: */
-h2, h3, h4, h5, h6 {
- color: #fff;
- text-shadow: 1px 1px 2px #000;
-
-}
-
-/* tables, figures */
-.fig caption {
- color: gray;
- text-align: center;
- /* Required for Mozilla */
- margin: auto;
-}
-.fig table {
- border: none;
- margin: auto;
-/* border-collapse: collapse; */
-}
-/* / */
-.fig.table th {
- border: none;
- background: gray;
- color: black;
-}
-/* [ */
-.fig.table td {
- border: none;
- background: silver;
- color: black;
- padding-left: 1em;
- padding-right: 1em;
- padding-top: 0.2em;
- padding-bottom: 0.2em;
-}
-/* < */
-
-.fig.image table {
- border: none;
- background: transparent;
- max-width: 100%;
-}
-.fig.image tr, .fig.image td {
- border: none;
- background: transparent;
- padding: 0;
-}
-
-.fig.image img
-{
- max-width: 900px;
-}
-
-/* */
-p {
- margin-right: 2%;
- text-align: justify;
- text-indent: 1em;
-}
-/* > */
-.example *
-{
- background: transparent;
-}
-.example table
-{
- margin: 0;
- padding: 0;
- table-layout: fixed;
- width: 100%;
- caption-side: top;
- overflow: auto;
-}
-.example caption
-{
- caption-side: top;
-
-}
-.example {
-}
-.example p {
- display: inline;
- margin: 0;
- padding: 0;
- text-align: center;
-}
-.example pre {
- margin-top: 0;
- font-family: Monospace;
- padding: 1em;
- border: solid 1px black;
- background: #222;
- color: white;
- display: block;
- overflow: auto;
- /* Every browser should support border radii */
-/* -moz-border-radius: 0.5em;
- border-radius: 0.5em; */
-}
-/* " */
-/*
- .quote:before {
- float: left;
- font-size: 500%;
- content: "\201C";
- }
- */
-/*
- blockquote:after {
- content: "\201D";
- }*/
-.quote blockquote {
- padding: 0.5em;
- margin-left: 0.5em;
- font-family: Serif;
- border-left: solid 0.4em gray;
- /* background: #333; */
- color: white;
-}
-/* ^ */
-small {
-/*
- color: silver;
- font-size: 50%;
- */
-}
-.footnote p {
- color: silver;
- margin: 0;
-}
-
-/* Popup footnotes */
-.footnote p {
- display: none;
-}
-.footnote p:target {
- display: block;
- overflow: auto;
- position: fixed;
- left: auto;
- bottom: 0;
- right: 0;
- max-width: 50%;
- border: solid 0.3em white;
- -moz-border-radius: 0.5em;
- background: black;
- padding: 0.2em;
-}
-
-/* { */
-.admonition * {
- background: transparent;
- color: white;
-}
-.admonition dl
-{
- display: table;
- margin: 0;
- padding: 0;
- background: #333;
- border: dotted black 0.3em;
- width: 90%
- margin-top: 0.5em;
- margin-bottom: 0.5em;
-}
-.admonition dt
-{
- display: table-cell;
- vertical-align: center;
- border-right: solid silver 0.4em;
- font-weight: bold;
- font-size: 115%;
- font-family: Serif;
- background: gray;
- width: 0;
- text-shadow: black 0.15em 0.15em 0.15em;
-}
-.admonition dd
-{
- padding-left: 0.4em;
- display: table-cell;
- width: 100%;
- text-align: justify;
-}
-
-.admonition table
-{
- margin: 0;
- padding: 0;
- background: #333;
- border: dotted black 0.3em;
- width: 90%
- margin-top: 0.5em;
- margin-bottom: 0.5em;
-}
-.admonition td {
- width: 100%;
- text-align: justify;
-}
-.admonition td:first-child:contains("Warning:") {
- background: #900;
-}
-.admonition td:first-child:contains("Caution:") {
- background: #960;
-}
-.admonition td:first-child:contains("Note:") {
- background: #690;
-}
-.admonition td:first-child {
- border-right: solid silver 0.4em;
- font-weight: bold;
- font-size: 115%;
- font-family: Serif;
- background: gray;
- width: 0;
- text-shadow: black 0.15em 0.15em 0.15em;
-}
-
-
-/* #(b) */
-/* b { color: olive; } */
-/* #(c) */
-tt {
- color: #7f0;
-}
-/* ! keywords ... */
-p em {
- color: gray;
- font-style: normal;
- font-weight: bold;
-}
-
-/* *, + */
-/* Bullet, numbe */
-li {
- color: #f0f;
-}
-/* Text */
-li span, li p {
- color: white;
-}
-li p {
- color: red;
- display: block;
-}
-ul {
- list-style-type: square;
-}
-dl {
- margin-left: 2%;
- margin-top: 1em;
-}
-/* = */
-dt {
- background: #181818;
- padding: 0.2em;
- font-variant: small-caps;
- font-weight: bold;
- color: #f0f;
-}
-dd {
- color: white;
- text-align: justify;
- margin-right: 5%;
-}
-dt a:link, dt a:visited {
- color: #f0f;
-}
-dt a:link:hover {
- color: silver;
- text-decoration: underline;
-}
diff --git a/session-manager/doc/nsm.png b/session-manager/doc/nsm.png
deleted file mode 100644
index 921b595..0000000
Binary files a/session-manager/doc/nsm.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/128x128/apps/non-session-manager.png b/session-manager/icons/hicolor/128x128/apps/non-session-manager.png
deleted file mode 100644
index 5a026df..0000000
Binary files a/session-manager/icons/hicolor/128x128/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/16x16/apps/non-session-manager.png b/session-manager/icons/hicolor/16x16/apps/non-session-manager.png
deleted file mode 100644
index 9621293..0000000
Binary files a/session-manager/icons/hicolor/16x16/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/192x192/apps/non-session-manager.png b/session-manager/icons/hicolor/192x192/apps/non-session-manager.png
deleted file mode 100644
index 440825d..0000000
Binary files a/session-manager/icons/hicolor/192x192/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/256x256/apps/non-session-manager.png b/session-manager/icons/hicolor/256x256/apps/non-session-manager.png
deleted file mode 100644
index a851d91..0000000
Binary files a/session-manager/icons/hicolor/256x256/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/32x32/apps/non-session-manager.png b/session-manager/icons/hicolor/32x32/apps/non-session-manager.png
deleted file mode 100644
index 5550873..0000000
Binary files a/session-manager/icons/hicolor/32x32/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/36x36/apps/non-session-manager.png b/session-manager/icons/hicolor/36x36/apps/non-session-manager.png
deleted file mode 100644
index 9d1b450..0000000
Binary files a/session-manager/icons/hicolor/36x36/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/48x48/apps/non-session-manager.png b/session-manager/icons/hicolor/48x48/apps/non-session-manager.png
deleted file mode 100644
index c249a03..0000000
Binary files a/session-manager/icons/hicolor/48x48/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/512x512/apps/non-session-manager.png b/session-manager/icons/hicolor/512x512/apps/non-session-manager.png
deleted file mode 100644
index c2e3cc7..0000000
Binary files a/session-manager/icons/hicolor/512x512/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/64x64/apps/non-session-manager.png b/session-manager/icons/hicolor/64x64/apps/non-session-manager.png
deleted file mode 100644
index 366088a..0000000
Binary files a/session-manager/icons/hicolor/64x64/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/72x72/apps/non-session-manager.png b/session-manager/icons/hicolor/72x72/apps/non-session-manager.png
deleted file mode 100644
index 8f02ceb..0000000
Binary files a/session-manager/icons/hicolor/72x72/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/96x96/apps/non-session-manager.png b/session-manager/icons/hicolor/96x96/apps/non-session-manager.png
deleted file mode 100644
index 46f4692..0000000
Binary files a/session-manager/icons/hicolor/96x96/apps/non-session-manager.png and /dev/null differ
diff --git a/session-manager/icons/hicolor/scalable/apps/non-session-manager.svg b/session-manager/icons/hicolor/scalable/apps/non-session-manager.svg
deleted file mode 100644
index 39104f6..0000000
--- a/session-manager/icons/hicolor/scalable/apps/non-session-manager.svg
+++ /dev/null
@@ -1,217 +0,0 @@
-
-
-
-