From d3c7e3b8f174ac51ab351386daad5bf57fc52a78 Mon Sep 17 00:00:00 2001 From: Nils <> Date: Sat, 5 Mar 2022 12:34:21 +0100 Subject: [PATCH] docs II --- docs/api/index.html | 1748 +++++++++++++++++++++++++++---------------- docs/index.html | 2 +- 2 files changed, 1101 insertions(+), 649 deletions(-) diff --git a/docs/api/index.html b/docs/api/index.html index 65694e7..9aa861e 100644 --- a/docs/api/index.html +++ b/docs/api/index.html @@ -473,6 +473,60 @@ body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-b +
  • 2. NSM OSC Protocol + +
    • +
  • 3. API Versions and Behaviour Changes + +
    • @@ -489,7 +543,7 @@ body.book #toc,body.book #preamble,body.book h1.sect0,body.book .sect1>h2{page-b "New Session Manager" is a community version of the "Non Session Manager" by Jonathan Moore Liles, who also wrote the majority of this API document, especially the API itself. The API is the same. Any -technical changes or differences in behaviour are described in [API Versions and Behaviour Changes]. +technical changes or differences in behaviour are described in API Versions and Behaviour Changes. All other changes to this document can be reviewed by accessing the git log. This document is licensed under CC-By-Sa v2.5. See LICENSE @@ -566,7 +620,7 @@ presented under a File or Project menu.

    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 [NSM OSC Protocol] section. In order to provide a +announce handshake described in the 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.

    @@ -726,6 +780,9 @@ access in this scenario. The numeric ID is a djb2 hash modulo (%) 65521 of the s

  • the OSC URL of the server that runs this session, the same as $NSM_URL.

    • +
  • +

    the PID of nsmd

    +
    • @@ -735,693 +792,1088 @@ access in this scenario. The numeric ID is a djb2 hash modulo (%) 65521 of the s 
    /home/johann/.local/share/nsm/cantatas/easter1751
 osc.udp://myuser.localdomain:11287/
-
-
-== 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`.
-`nsmd` itself is using UDP only.
-
-
-
-=== Establishing a Connection
-
-==== Announce
-
-At launch, the client MUST check the environment for the value of `NSM_URL`. If present, the client
+3022
    +
    +
    + + + + + +
    +

    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. +nsmd itself is using UDP only.

    +
    +
    +

    2.1. Establishing a Connection

    +
    +

    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: - -[source%nowrap,OSC] ----- -/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 +/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 briefly 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 +process briefly 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 -[options="header", stripes=even] -|=== - -|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: - -[source%nowrap,OSC] ----- -/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 +like Python can be more challenging.

    +
    + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Table 1. Available Client Capabilities
    NameDescription

    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

    +
    +
    +

    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 "New Session Manager", or it might say "Non Session Manager" etc. 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 -[options="header", stripes=even] -|=== - -|Name | Description - -|server-control | client-to-server control -|broadcast | server responds to /nsm/server/broadcast message -|optional-gui | server responds to optional-gui messages. This capability is always present and MUST be supported by any server implementation. - -|=== - -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: - - -[source%nowrap,OSC] ----- -/error "/nsm/server/announce" i:error_code s:error_message ----- - -The following table defines possible values of `error_code`: - -.Response codes -[options="header", stripes=even] -|=== - -|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 (`nsmd`) from the -same socket used by the client in its `announce` message (by using `lo_send_from`) AFTER the action has +the user.

    +
    +
    +

    capabilities will be a string containing a colon separated list of special server capabilities.

    +
    +
    +

    Presently, the server capabilities are:

    +
    + + ++++ + + + + + + + + + + + + + + + + + + + + +
    Table 2. Available Server Capabilities
    NameDescription

    server-control

    client-to-server control

    broadcast

    server responds to /nsm/server/broadcast message

    optional-gui

    server responds to optional-gui messages. This capability is always present and MUST be supported by any server implementation.

    +
    +

    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:

    +
    + + ++++ + + + + + + + + + + + + + + + + + + + + +
    Table 3. Response codes
    CodeMeaning

    ERR_GENERAL

    General Error

    ERR_INCOMPATIBLE_API

    Incompatible API version

    ERR_BLACKLISTED

    Client has been blacklisted.

    +
    +
    +
    +

    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 (nsmd) 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 <<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": - -[source%nowrap,OSC] ----- -/reply s:path s:message ----- - -[source%nowrap,OSC] ----- -/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 +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 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
    +
    +
    +
    +

    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. - - -[#server-to-client-control-messages-open] -==== Open - -[source%nowrap,OSC] ----- -/nsm/client/open s:path_to_instance_specific_project s:display_name s:client_id ----- - -`path_to_instance_specific_project` is a path name in the form client_name.ID, assigned to the +soon after having responded to a save message.

    +
    +
    +
    +

    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 in the form client_name.ID, assigned to the client for storing its project data. The client MUST choose one of the four strategies below to save, so that every file in the session can be traced back to a client and, vice versa, a client -name.ID can be used to look up all its files. (For example to clean up the session dir) - -* The client has no state and does not save at all - ** and it MUST NOT misuse e.g. ~/.config to save session specific information e.g. synth-instrument settings -* The client may use the path client_name.ID directly, resulting in a file client_name.ID in the session directory -* The client may append its native file extension (e.g. `.json`) to the path client_name.ID -* The client may use the path as directory, creating arbitrary files below, for example recorded .wav. - ** and it MUST NOT use the client ID below this point. This way the data stays transferable by hand to another client instance (in another session). - ** best case practice is to always use the same file names, for example `client_name.ID/savefile.json` - -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 +name.ID can be used to look up all its files. (For example to clean up the session dir)

    +
    +
    +
      +
    • +

      The client has no state and does not save at all

      +
      +
        +
      • +

        and it MUST NOT misuse e.g. ~/.config to save session specific information e.g. synth-instrument settings

        +
        • +
      +
      +
      • +
    • +

      The client may use the path client_name.ID directly, resulting in a file client_name.ID in the session directory

      +
      • +
    • +

      The client may append its native file extension (e.g. .json) to the path client_name.ID

      +
      • +
    • +

      The client may use the path as directory, creating arbitrary files below, for example recorded .wav.

      +
      +
        +
      • +

        and it MUST NOT use the client ID below this point. This way the data stays transferable by hand to another client instance (in another session).

        +
        • +
      • +

        best case practice is to always use the same file names, for example client_name.ID/savefile.json

        +
        • +
      +
      +
      • +
    +
    +
    +

    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 -then such an application MUST PRE-PEND the provided `client_id` string, followed by "/", to any +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 +then such an application MUST PRE-PEND the provided client_id string, followed by "/", 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. Carla or Non-Mixer) MUST PRE-PEND -`client_id` value, followed by "/", to the client names they register with JACK and the application -determined part MUST be unique for that (JACK) client. - -For example, Carla is a plugin-host that loads each plugin as JACK client. -Suitable JACK client names are: `carla-jack-multi.nBAF/ZynAddSubFx` or `carla-jack-multi.nBAF/Helm` -Please note that ZynAddSubFx and Helm are *not ports* but clients. Each of them can have any number -of audio and midi ports below them. - -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` (renaming JACK-clients is not possible, only ports). - -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: - -[source%nowrap,OSC] ----- -/reply "/nsm/client/open" s:message ----- - -Or - -[source%nowrap,OSC] ----- -/error "/nsm/client/open" i:error_code s:message ----- - - -.Response codes -[options="header", stripes=even] -|=== - -|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 - -[source%nowrap,OSC] ----- -/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). - -===== Response - -[source%nowrap,OSC] ----- -/reply "/nsm/client/save" s:message ----- - -Or - -[source%nowrap,OSC] ----- -/error "/nsm/client/save" i:error_code s:message ----- - - -.Response codes -[options="header", stripes=even] -|=== - -|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 +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. Carla or Non-Mixer) MUST PRE-PEND +client_id value, followed by "/", to the client names they register with JACK and the application +determined part MUST be unique for that (JACK) client.

    +
    +
    +

    For example, Carla is a plugin-host that loads each plugin as JACK client. +Suitable JACK client names are: carla-jack-multi.nBAF/ZynAddSubFx or carla-jack-multi.nBAF/Helm +Please note that ZynAddSubFx and Helm are not ports but clients. Each of them can have any number +of audio and midi ports below them.

    +
    +
    +

    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 (renaming JACK-clients is not possible, only ports).

    +
    +
    +

    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.

    +
    +
    +
    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
    +
    +
    + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Table 4. Response codes
    CodeMeaning

    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

    +
    +
    +
    +

    2.2.3. 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).

    +
    +
    +
    2.2.3.1. Response
    +
    +
    +
    /reply "/nsm/client/save" s:message
    +
    +
    +
    +

    Or

    +
    +
    +
    +
    /error "/nsm/client/save" i:error_code s:message
    +
    +
    + + ++++ + + + + + + + + + + + + + + + + + + + + +
    Table 5. Response codes
    CodeMeaning

    ERR

    General Error

    ERR_SAVE_FAILED

    Project could not be saved

    ERR_NOT_NOW

    Operation cannot be completed at this time

    +
    +
    +
    +
    +

    2.3. Server to Client Informational Messages

    +
    +

    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. - -[source%nowrap,OSC] ----- -/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 +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.

    +
    +
    +
    +

    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. - -[source%nowrap,OSC] ----- -/nsm/client/show_optional_gui ----- - -[source%nowrap,OSC] ----- -/nsm/client/hide_optional_gui ----- - -This message does not require a response. - - - -=== Client to Server Informational Messages - -==== Optional GUI - -If the client has specified the `optional-gui` capability, then it MUST send this message whenever +separate program, it should be killed.

    +
    +
    +
    +
    /nsm/client/show_optional_gui
    +
    +
    +
    +
    +
    /nsm/client/hide_optional_gui
    +
    +
    +
    +

    This message does not require a response.

    +
    +
    +
    +
    +

    2.4. Client to Server Informational Messages

    +
    +

    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 its -announce message to indicate the initial visibility state of the optional GUI. - -The client SHOULD always start hidden, if not saved as visible. That implies the first load, after -adding to the session, SHOULD always be hidden. - -It is the responsibility of the client to remember the visibility state of its GUI across session -loads. - -[source%nowrap,OSC] ----- -/nsm/client/gui_is_hidden ----- - -[source%nowrap,OSC] ----- -/nsm/client/gui_is_shown ----- - -No response will be delivered. - - -==== Progress - -[source%nowrap,OSC] ----- -/nsm/client/progress f:progress ----- - -For potentially time-consuming operations, such as `save` and `open`, progress updates may be +announce message to indicate the initial visibility state of the optional GUI.

    +
    +
    +

    The client SHOULD always start hidden, if not saved as visible. That implies the first load, after +adding to the session, SHOULD always be hidden.

    +
    +
    +

    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.

    +
    +
    +
    +

    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 MUST include `:progress:` in their `announce` -capability string. - - -==== Dirtiness - -[source%nowrap,OSC] ----- -/nsm/client/is_dirty ----- - -[source%nowrap,OSC] ----- -/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 and use this capability MUST include `:dirty:` in their `announce` capability string. - -==== Status Messsages - -[source%nowrap,OSC] ----- -/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` MUST be a number from 0 -to 3, 3 being the most important. - -Clients which have and use this capability MUST include `:message:` in their `announce` capability -string. - - -=== Error Code Definitions - -.Error Code Definitions -[options="header", stripes=even] -|=== - -|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 +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 MUST include :progress: in their announce +capability string.

    +
    +
    +
    +

    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 and use this capability MUST include :dirty: in their announce capability string.

    +
    +
    +
    +

    2.4.4. Status Messsages

    +
    +
    +
    /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 MUST be a number from 0 +to 3, 3 being the most important.

    +
    +
    +

    Clients which have and use this capability MUST include :message: in their announce capability +string.

    +
    +
    +
    +
    +

    2.5. Error Code Definitions

    + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Table 6. Error Code Definitions
    Symbolic NameInteger 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

    +
    +
    +

    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. - - -=== 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: - -[source%nowrap,OSC] ----- -/reply s:path s:message ----- - -[source%nowrap,OSC] ----- -/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 -[options="header", stripes=even] -|=== - -|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. - ** Afer listing the last session one final `/reply` with `/nsm/server/list, ""` will be send. That is an empty string. - - -==== Client to Client Communication - -If the server includes `:broadcast:` in its capability string, then clients may send broadcast +/nsm/server/save message to the server, rather than requiring the user to switch to the session +management interface to effect the save.

    +
    +
    +
    +

    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:

    +
    + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Table 7. Responses
    CodeMeaning

    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.

        +
        • +
      • +

        Afer listing the last session one final /reply with /nsm/server/list, "" will be send. That is an empty string.

        +
        • +
      +
      +
      • +
    +
    +
    +

    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: - -[source%nowrap,OSC] ----- -/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: - - -[source%nowrap,OSC] ----- -/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. - - -[source%nowrap,OSC] ----- -/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. - - -== API Versions and Behaviour Changes - -Here we will document all technical changes or differences in behaviour together with their API and -project version numbers. The term "original" refers to Non Session Manager and "new" refers to New -Session Manager. - -Version numbers follow link:https://semver.org/spec/v2.0.0.html[Semantic Versioning 2.0.0] - -.Semantic Versioning Scheme +/nsm/server/broadcast.

    +
    +
    +

    The format of this message is as follows:

    +
    +
    +
    +
    /nsm/server/broadcast s:path [arguments...]
    -

    Given a version number MAJOR.MINOR.PATCH, increment the:

    +

    The message will then be relayed to all clients in the session at the path path (with the +arguments shifted by one).

    -

    MAJOR version when you make incompatible API changes, -MINOR version when you add functionality in a backwards compatible manner, and -PATCH version when you make backwards compatible bug fixes.

    +

    For example the message:

    -
    .NSM Version Numbers
-[options="header", stripes=even]
-|===
-
-|Subject     | Version
-
-|Non Session Manager at moment of fork          | 1.2 (June 2020)
-|Non Session Manager API    | 1.0 link:https://github.com/original-male/non/blob/master/session-manager/src/nsmd.C[NON nsmd.C]
-|Original API Document      | 1.0 link:http://non.tuxfamily.org/nsm/API.html[non.tuxfamily.org/nsm/API.html]
-|New Session Manager        | 1.6.0
-|New Session Manager API    | 1.1.2 link:https://github.com/jackaudio/new-session-manager/blob/master/src/nsmd.cpp[NEW nsmd.cpp]
-|New API Document   | 1.5.0 link:#[Here]
-
-|===
-
-
-=== Guidelines
-
-The most important factor in decision making is to keep client compatibility at 100%.
-No client will ever receive an unrequested OSC message except those in API 1.0.0.
-
-Messages that drastically change existing `/nsm/client/` or `/nsm/server` behaviour require an
-inrecement to `API_VERSION_MAJOR`, which we want to avoid.
-
-`nsmd` checks if the clients `API_VERSION_MAJOR` is greater than its own and refuses the client
-with `ERR_INCOMPATIBLE_API`.
-
-All changes (that concern client/server behaviour) that increment `API_VERSION_MINOR` will be
-request-only or gated by new capabilities (e.g. `:optional-gui:`). `nsmd` will not send any
-messages if a capability was not sent by the client in <<Announce,`announce`>>. This includes
-mostly optional features about requesting extra information.
-
-New actions for server-control, for example a hypothetical `/nsm/server/save_as`, which would be
-triggered by the client and would only be *answered* by the server ("no unrequested message") will
-increment `API_VERSION_MINOR`.
+
    /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.

    +
    +
    +
    +
    +
    +
    +

    3. API Versions and Behaviour Changes

    +
    +
    +

    Here we will document all technical changes or differences in behaviour together with their API and +project version numbers. The term "original" refers to Non Session Manager and "new" refers to New +Session Manager.

    +
    +
    +

    Version numbers follow Semantic Versioning 2.0.0

    +
    +
    +
    Semantic Versioning Scheme
    +
    +
    Given a version number MAJOR.MINOR.PATCH, increment the:
 
-All changes that increment `API_VERSION_PATCH` will not have any effect on behaviour, except to
+MAJOR version when you make incompatible API changes,
+MINOR version when you add functionality in a backwards compatible manner, and
+PATCH version when you make backwards compatible bug fixes.
    +
    +
    + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Table 8. NSM Version Numbers
    SubjectVersion

    Non Session Manager at moment of fork

    1.2 (June 2020)

    Non Session Manager API

    1.0 NON nsmd.C

    Original API Document

    1.0 non.tuxfamily.org/nsm/API.html

    New Session Manager

    1.6.0

    New Session Manager API

    1.1.2 NEW nsmd.cpp

    New API Document

    1.5.0 Here

    +
    +

    3.1. Guidelines

    +
    +

    The most important factor in decision making is to keep client compatibility at 100%. +No client will ever receive an unrequested OSC message except those in API 1.0.0.

    +
    +
    +

    Messages that drastically change existing /nsm/client/ or /nsm/server behaviour require an +inrecement to API_VERSION_MAJOR, which we want to avoid.

    +
    +
    +

    nsmd checks if the clients API_VERSION_MAJOR is greater than its own and refuses the client +with ERR_INCOMPATIBLE_API.

    +
    +
    +

    All changes (that concern client/server behaviour) that increment API_VERSION_MINOR will be +request-only or gated by new capabilities (e.g. :optional-gui:). nsmd will not send any +messages if a capability was not sent by the client in announce. This includes +mostly optional features about requesting extra information.

    +
    +
    +

    New actions for server-control, for example a hypothetical /nsm/server/save_as, which would be +triggered by the client and would only be answered by the server ("no unrequested message") will +increment API_VERSION_MINOR.

    +
    +
    +

    All changes that increment API_VERSION_PATCH will not have any effect on behaviour, except to fix clear problems, where "problem" is defined by having a different effect than described in this -document, which includes technical problems such as crashes. - -All messages regarding GUI-communication that start with `/nsm/gui/...` were undocumented in API -1.0.0 and only used by `non-session-manager` / `nsm-legacy-gui`. Until properly documented in this +document, which includes technical problems such as crashes.

    +
    +
    +

    All messages regarding GUI-communication that start with /nsm/gui/…​ were undocumented in API +1.0.0 and only used by non-session-manager / nsm-legacy-gui. Until properly documented in this document this part of the API is considered unstable and may change at any time without notice. -However, when changing already existing messages and behaviour it MAY increment `API_VERSION_MINOR` -or `API_VERSION_PATCH`. In that case it will appear in the list below. - -Last factor of compatibility is that any unknown message sent to `nsmd` will just print a warning +However, when changing already existing messages and behaviour it MAY increment API_VERSION_MINOR +or API_VERSION_PATCH. In that case it will appear in the list below.

    +
    +
    +

    Last factor of compatibility is that any unknown message sent to nsmd will just print a warning message to stdout, but will otherwise be ignored. This secures a stable server, even when a client -misbehaves and sends too-new messages outside of announced :capabilites: - -=== Changes in API Version 1.1.0 - -Rewritten API document without code changes to adapt to existing code or existing client behaviour: - -* Changed versioning scheme to Semantic Versioning with three positions Major.Minor.Patch -* <<Quit or Exit>> SHOULD hide instead of exiting when :optional-gui: is supported and MAY not - act on the quit through menu otherwise. -* <<#server-to-client-control-messages-open,Open>>: Make clear that there are only certain - possibilities for save paths. We added MUST because the rule was just implied before. -* <<#server-to-client-control-messages-open,Open>>: Make clear that the delimiter for - multi-jack clients is "/". -* <<Optional GUI>> SHOULD start hidden, always after a fresh add to the session. After that saving - the visibility state may override it for next time. -* <<Progress>> MUST be announced in :capabilities: . Before there was a lower case "should", - which means nothing. Parallel-examples in the specs cleary say that supporting optional features must be announced first. - ** Same for <<Dirtiness>> and <<Status Messsages>>. -* <<Status Messsages>> have priority numbers between 0 and 3, so they MUST send that. - It was never an arbitrary value. - -Code changes: - -* <<Server Control API>>: `/nsm/server/list` chain of single OSC messages, one for each session, - is now finalized with sending and empty string "" as session name. Previously this was just - a symbolically irrelevant console message `"Done."` -* Replies to `/nsm/server/save` etc. will now be sent back to the sender and not falsely to the last - client who replied to `/nsm/client/save`. This alone would only require API_VERSION_PATCH - increment, but we are already incrementing minor. -* <<Server Control API>>: `/nsm/server/add` was replying with an undocumented error code on success. - Instead, as this document always specificed, it now sends `"/reply", path, "Launched."`. - Again, this would have been just API_VERSION_PATCH on its own. - -Undocumented (Unstable) `/nsm/gui` protocol - -* Send client status after a GUI attaches to running server. This - was not happening before, but it was the intention. It was just broken in nsmd.cpp. This alone - would only require API_VERSION_PATCH increment, but we are already incrementing minor. -* Send label "launch error!" when a program is added (or loaded) that - does not exist in $PATH. This requires no adaptation of any client, server or GUI because labels - are arbitrary already and this is not meant for automatic parsing, but as user information. -* `/nsm/gui/session/name` will now always send the same parameter format, regardless of how the session was opened: - simple-session-name, relative session path with subdirs below session-root. -* When a GUI announces itself to nsmd it will receive the absolute path to the session directory - through the message `/nsm/gui/session/root`. This is not a new addition but was already in - non-session-manager git. - -=== Changes in API Version 1.1.1 - -* Server-capability :optional-gui: is now mandatory for SERVER implementations. Reasoning: +misbehaves and sends too-new messages outside of announced :capabilites:

    +
    +
    +
    +

    3.2. Changes in API Version 1.1.0

    +
    +

    Rewritten API document without code changes to adapt to existing code or existing client behaviour:

    +
    +
    +
      +
    • +

      Changed versioning scheme to Semantic Versioning with three positions Major.Minor.Patch

      +
      • +
    • +

      Quit or Exit SHOULD hide instead of exiting when :optional-gui: is supported and MAY not +act on the quit through menu otherwise.

      +
      • +
    • +

      Open: Make clear that there are only certain +possibilities for save paths. We added MUST because the rule was just implied before.

      +
      • +
    • +

      Open: Make clear that the delimiter for +multi-jack clients is "/".

      +
      • +
    • +

      Optional GUI SHOULD start hidden, always after a fresh add to the session. After that saving +the visibility state may override it for next time.

      +
      • +
    • +

      Progress MUST be announced in :capabilities: . Before there was a lower case "should", +which means nothing. Parallel-examples in the specs cleary say that supporting optional features must be announced first.

      +
      + +
      +
      • +
    • +

      Status Messsages have priority numbers between 0 and 3, so they MUST send that. +It was never an arbitrary value.

      +
      • +
    +
    +
    +

    Code changes:

    +
    +
    +
      +
    • +

      Server Control API: /nsm/server/list chain of single OSC messages, one for each session, +is now finalized with sending and empty string "" as session name. Previously this was just +a symbolically irrelevant console message "Done."

      +
      • +
    • +

      Replies to /nsm/server/save etc. will now be sent back to the sender and not falsely to the last +client who replied to /nsm/client/save. This alone would only require API_VERSION_PATCH +increment, but we are already incrementing minor.

      +
      • +
    • +

      Server Control API: /nsm/server/add was replying with an undocumented error code on success. +Instead, as this document always specificed, it now sends "/reply", path, "Launched.". +Again, this would have been just API_VERSION_PATCH on its own.

      +
      • +
    +
    +
    +

    Undocumented (Unstable) /nsm/gui protocol

    +
    +
    +
      +
    • +

      Send client status after a GUI attaches to running server. This +was not happening before, but it was the intention. It was just broken in nsmd.cpp. This alone +would only require API_VERSION_PATCH increment, but we are already incrementing minor.

      +
      • +
    • +

      Send label "launch error!" when a program is added (or loaded) that +does not exist in $PATH. This requires no adaptation of any client, server or GUI because labels +are arbitrary already and this is not meant for automatic parsing, but as user information.

      +
      • +
    • +

      /nsm/gui/session/name will now always send the same parameter format, regardless of how the session was opened: +simple-session-name, relative session path with subdirs below session-root.

      +
      • +
    • +

      When a GUI announces itself to nsmd it will receive the absolute path to the session directory +through the message /nsm/gui/session/root. This is not a new addition but was already in +non-session-manager git.

      +
      • +
    +
    +
    +
    +

    3.3. Changes in API Version 1.1.1

    +
    +
      +
    • +

      Server-capability :optional-gui: is now mandatory for SERVER implementations. Reasoning: This is an important core feature of NSM and thus will be treated as such by guaranteeing it to exist. After looking at all currently known clients and server-implementations it turns out that all servers support :optional-gui: and the vast majority of clients not only support it, but actually assume it -and do _not_ test for the server capability, as it was written in this document. +and do not test for the server capability, as it was written in this document. There are now two choices: Adjust this document to the (good) reality or consider all clients broken. Summary: We consider this API document wrong and therefore fix it, thus increasing API version -patch-level from 1.1.0 to 1.1.1 - -* Add API-section "Subdirectories / Hierarchical Structure" that explains the session directory. +patch-level from 1.1.0 to 1.1.1

      +
      • +
    • +

      Add API-section "Subdirectories / Hierarchical Structure" that explains the session directory. This behaviour was already the case for nsm-legacy-gui and nsmd 1.5.0 was patched to adhere to this -behaviour more strictly as well, removing false session entries in 3rd party clients such as Agordejo. - -=== Changes in API Version 1.1.2 - -* nsmd now follows the XDG Base Directory Specifications for it's session root and lock files. This -if of no consequence to clients but required documentation nevertheless, which was described as -"background information" in the new section. -

    +behaviour more strictly as well, removing false session entries in 3rd party clients such as Agordejo.

    + +
    +
    +

    3.4. Changes in API Version 1.1.2

    +
    +
      +
    • +

      nsmd now follows the XDG Base Directory Specifications for it’s session root and lock files. This +if of no consequence to clients but required documentation nevertheless, which was described as +"background information" in the new section.

      +
      • +
    @@ -1430,7 +1882,7 @@ if of no consequence to clients but required documentation nevertheless, which w diff --git a/docs/index.html b/docs/index.html index ec143f2..97cf4a0 100644 --- a/docs/index.html +++ b/docs/index.html @@ -557,7 +557,7 @@ Documentation and tutorials for software-developers will be added at a later dat