Assists music production by grouping standalone programs into sessions. Community version of "Non Session Manager".
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

822 lines

  1. ////
  2. This is "asciidoctor", not plain "asciidoc".
  4. ////
  5. ////
  6. This documentation is licensed under the Creative Commons Attribution-ShareAlike 2.5 International License.
  7. To view a copy of this license, visit or send a
  8. letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
  9. A copy of the license has been provided in the file documentation/API/LICENSE.
  10. ////
  11. :authors: Jonathan Moore Liles, Nils Hilbricht
  12. :revnumber: API 1.1.0
  13. :revremark: License CC-By-SA v2.5
  14. :iconfont-remote!:
  15. :!webfonts:
  16. :sectnums:
  17. :sectnumlevels: 4
  18. :toc:
  19. :toc-title: Table of Contents
  20. :toclevels: 4
  21. = New Session Manager - API
  22. IMPORTANT: "New Session Manager" is a community version of the
  23. link:["Non Session Manager" by Jonathan Moore Liles], who also
  24. wrote the majority of this API document, especially the API itself. *The API is the same*. Any
  25. technical changes or differences in behaviour are described in <<API Versions and Behaviour Changes>>.
  26. All other changes to this document can be reviewed by accessing the git log. This document is
  27. licensed under CC-By-Sa v2.5. See link:[LICENSE]
  29. NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
  30. described in link:[RFC 2119].
  31. The "New Session Manager"-API is used by many music and audio programs in Linux distributions
  32. to allow any number of independent programs to be managed together as part of a logical session
  33. (i.e. a song). Thus, operations such as loading and saving are synchronized.
  34. The API comprises a simple Open Sound Control (OSC) based protocol, along with some behavioral
  35. guidelines, which can easily be implemented by various applications.
  36. This project contains a program called `nsmd` which is an implementation of the server side of
  37. the NSM API. `nsmd` can be controlled by direct OSC messages, or (more commonly) a GUI:
  38. Included in this package is the `nsm-legacy-gui`, which gets symlinked to "non-session-manager`.
  39. Another GUI is "Agordejo". Other applications exist that (partially) support the NSM API and are able
  40. to load clients, but they do not use the New-Session-Manager (or Non-Session-Manager) implementation
  41. and are therefore out of scope for this document.
  42. However, the same server-side API can also be implemented by other programs (such as Carla),
  43. although consistency and robustness will likely suffer if non-NSM compliant clients are allowed to
  44. participate in a session.
  45. There is no direct dependency for client implementations, as long as they
  46. can send and receive OSC.
  47. Some clients use `liblo` (the OSC library), which becomes a dependency if you choose to implement
  48. NSM-support with the provided header file `nsm.h` (`extras/nsm.h/nsm.h` in the git repository).
  49. Some clients use the provided single-file python library `pynsm` (`extras/pynsm/` in the git repository)
  50. which has no dependencies outside the Python3 standard library.
  51. The aim of this project is to thoroughly define the behavior required of clients. Often the
  52. difficulty with other session-management approaches has been not in implementing code-support for
  53. them, but in not defining rules and behaviour clearly enough.
  54. As written above unambiguous rules are created by using RFC 2119 in this document. For the good of
  55. the user, these rules are meant to be followed and are non-negotiable. If an application does not
  56. conform to this specification it should be considered broken. Consistency across applications under
  57. session management is very important for a good user experience.
  58. == Client Behavior Under Session Management
  59. Most graphical applications make available to the user a common set of file operations, typically
  60. presented under a File or Project menu.
  61. These are: New, Open, Save, Save As, Close and Quit or Exit.
  62. The following sub-sections describe how these options should behave when the application is part of
  63. an NSM session. These rules only apply when session management is active, that is, after the
  64. `announce` handshake described in the <<NSM OSC Protocol>> section. In order to provide a
  65. consistent and predictable user experience, it is critically important for applications to adhere
  66. to these guidelines.
  67. === File Menu
  68. ==== New
  69. This option MAY empty/reset the current file or project (possibly after user confirmation).
  70. It MUST NOT allow the user to create a new project/file in another location.
  71. ==== Open
  72. This option MUST be disabled.
  73. The application MAY elect to implement an option called "Import into Session", which creates a
  74. copy of a file/project which is then saved at the session path provided by NSM.
  75. ==== Save
  76. This option should behave as normal, saving the current file/project as established by the NSM
  77. `open` message.
  78. This option MUST NOT present the user with a choice of where to save the file.
  79. ==== Save As
  80. This option MUST be disabled.
  81. The application MAY elect to implement an option called 'Export from Session', which
  82. creates a copy of the current file/project which is then saved in a user-specified location outside
  83. of the session path provided by NSM.
  84. ==== Close (as distinguished from Quit or Exit)
  85. This option MUST be disabled unless its meaning is to disconnect the application from session
  86. management.
  87. ==== Quit or Exit
  88. This option MAY behave as normal (possibly asking the user to confirm exiting), or MAY do nothing
  89. to only allow quit from the session-manager control.
  90. When the client supports :optional-gui: this option SHOULD be replaced with hiding the client's GUI
  91. so a quit by window manager hides.
  92. === Data Storage
  93. ==== Internal Files
  94. All project specific data created by a client MUST be stored in the per-client storage area
  95. provided by NSM. This includes all recorded audio and MIDI files, snapshots, etc. Only global
  96. configuration items, exports, and renders of the project may be stored elsewhere (wherever the user
  97. specifies).
  98. ==== External Files
  99. Files required by the project but external to it (typically read-only data such as audio samples)
  100. SHOULD be referenced by creating a symbolic link within the assigned session area, and then
  101. referring to the symlink. This allows sessions to be archived and transported simply (e.g. with
  102. "tar -h") by tools that have no knowledge of the project formats of the various clients in the
  103. session. The symlinks thus created should, at the very least, be named after the files they refer
  104. to. Some unique component may be required to prevent collisions.
  105. == NSM OSC Protocol
  106. All message parameters are REQUIRED. All messages MUST be sent from the same socket as the `announce`
  107. message, using the `lo_send_from` method of liblo or its equivalent, as the server uses the return
  108. addresses to distinguish between clients.
  109. Clients MUST create thier OSC servers using the same protocol (UDP,TCP) as found in `NSM_URL`.
  110. `nsmd` itself is using UDP only.
  111. === Establishing a Connection
  112. ==== Announce
  113. At launch, the client MUST check the environment for the value of `NSM_URL`. If present, the client
  114. MUST send the following message to the provided address as soon as it is ready to respond to the
  115. `/nsm/client/open` event:
  116. [source%nowrap,OSC]
  117. ----
  118. /nsm/server/announce s:application_name s:capabilities s:executable_name i:api_version_major i:api_version_minor i:pid
  119. ----
  120. If `NSM_URL` is undefined, invalid, or unreachable, then the client should proceed assuming that
  121. session management is unavailable.
  122. `api_version_major` and `api_version_minor` must be the two parts of the version number of the NSM API
  123. as defined by this document.
  124. Note that if the application intends to register JACK clients, `application_name` MUST be the same as
  125. the name that would normally be passed to `jack_client_open`. For example, Non-Mixer sends
  126. "Non-Mixer" as its `application_name`. Applications MUST NOT register their JACK clients until
  127. receiving an `open` message; the `open` message will provide a unique client name prefix suitable for
  128. passing to JACK. This is probably the most complex requirement of the NSM API, but it isn't
  129. difficult to implement, especially if the application simply wishes to delay its initialization
  130. process briefly while awaiting the `announce` reply and subsequent `open` message.
  131. `capabilities` MUST be a string containing a colon separated list of the special capabilities the
  132. client possesses. e.g. `:dirty:switch:progress:`
  133. `executable_name` MUST be the executable name that the program was launched with. For C programs,
  134. this is simply the value of `argv[0]`. Note that hardcoding the name of the program here is not the
  135. same as using, as the user may have launched the program from a script with a different name using
  136. exec, or have created a symlink to the program. Getting the correct value in scripting languages
  137. like Python can be more challenging.
  138. .Available Client Capabilities
  139. [options="header", stripes=even]
  140. |===
  141. |Name | Description
  142. |switch | client is capable of responding to multiple `open` messages without restarting
  143. |dirty | client knows when it has unsaved changes
  144. |progress | client can send progress updates during time-consuming operations
  145. |message | client can send textual status updates
  146. |optional-gui | client has an optional GUI
  147. |===
  148. ==== Response
  149. The server will respond to the client's announce message with the following message:
  150. [source%nowrap,OSC]
  151. ----
  152. /reply "/nsm/server/announce" s:message s:name_of_session_manager s:capabilities
  153. ----
  154. `message` is a welcome message.
  155. The value of `name_of_session_manager` will depend on the implementation of the NSM server. It
  156. might say "New Session Manager", or it might say "Non Session Manager" etc. This is for display to
  157. the user.
  158. `capabilities` will be a string containing a colon separated list of special server capabilities.
  159. Presently, the server `capabilities` are:
  160. .Available Server Capabilities
  161. [options="header", stripes=even]
  162. |===
  163. |Name | Description
  164. |server-control | client-to-server control
  165. |broadcast | server responds to /nsm/server/broadcast message
  166. |optional-gui | server responds to optional-gui messages. If this capability is not present then clients with optional-guis MUST always keep them visible
  167. |===
  168. A client should not consider itself to be under session management until it receives this response.
  169. For example, the Non applications activate their "SM" blinkers at this time.
  170. If there is an error, a reply of the following form will be sent to the client:
  171. [source%nowrap,OSC]
  172. ----
  173. /error "/nsm/server/announce" i:error_code s:error_message
  174. ----
  175. The following table defines possible values of `error_code`:
  176. .Response codes
  177. [options="header", stripes=even]
  178. |===
  179. |Code | Meaning
  180. |ERR_GENERAL | General Error
  181. |ERR_INCOMPATIBLE_API | Incompatible API version
  182. |ERR_BLACKLISTED | Client has been blacklisted.
  183. |===
  184. === Server to Client Control Messages
  185. Compliant clients MUST accept the client control messages described in this section. All client
  186. control messages REQUIRE a response. Responses MUST be delivered back to the sender (`nsmd`) from the
  187. same socket used by the client in its `announce` message (by using `lo_send_from`) AFTER the action has
  188. been completed or if an error is encountered. The required response is described in the subsection
  189. for each message.
  190. If there is an error and the action cannot be completed, then `error_code` MUST be set to a valid
  191. error code (see <<Error Code Definitions>>) and `message` to a string describing the problem
  192. (suitable for display to the user).
  193. The reply can take one of the following two forms, where path MUST be the `path` of the message being
  194. replied to (e.g. "nsm/client/save":
  195. [source%nowrap,OSC]
  196. ----
  197. /reply s:path s:message
  198. ----
  199. [source%nowrap,OSC]
  200. ----
  201. /error s:path i:error_code s:message
  202. ----
  203. ==== Quit
  204. There is no message for this. Clients will receive the Unix SIGTERM signal and MUST close cleanly
  205. IMMEDIATELY, without displaying any kind of dialog to the user and regardless of whether or not
  206. unsaved changes would be lost. When a session is closed the application will receive this signal
  207. soon after having responded to a `save` message.
  208. [#server-to-client-control-messages-open]
  209. ==== Open
  210. [source%nowrap,OSC]
  211. ----
  212. /nsm/client/open s:path_to_instance_specific_project s:display_name s:client_id
  213. ----
  214. `path_to_instance_specific_project` is a path name in the form client_name.ID, assigned to the
  215. client for storing its project data. The client MUST choose one of the four strategies below to
  216. save, so that every file in the session can be traced back to a client and, vice versa, a client
  217. name.ID can be used to look up all its files. (For example to clean up the session dir)
  218. * The client has no state and does not save at all
  219. ** and it MUST NOT misuse e.g. ~/.config to save session specific information e.g. synth-instrument settings
  220. * The client may use the path client_name.ID directly, resulting in a file client_name.ID in the session directory
  221. * The client may append its native file extension (e.g. `.json`) to the path client_name.ID
  222. * The client may use the path as directory, creating arbitrary files below, for example recorded .wav.
  223. ** 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).
  224. ** best case practice is to always use the same file names, for example `client_name.ID/savefile.json`
  225. If a project exists at the path, the client MUST immediately open it.
  226. If a project does not exist at the path, then the client MUST immediately create and open a new one
  227. at the specified path or, for clients which hold all their state in memory, store the path for
  228. later use when responding to the `save` message.
  229. No file or directory will be created at the specified path by the server. It is up to the client to
  230. create what it needs.
  231. For clients which HAVE NOT specified the `:switch:` capability, the `open` message will only be
  232. delivered once, immediately following the `announce` response.
  233. For clients which HAVE specified the `:switch:` capability, the client MUST immediately switch to the
  234. specified project or create a new one if it doesn't exist.
  235. Clients which are incapable of switching projects or are prone to crashing upon switching MUST NOT
  236. include `:switch:` in their capability string.
  237. If the user the is allowed to run two or more instances of the application simultaneously
  238. then such an application MUST PRE-PEND the provided `client_id` string, followed by "/", to any
  239. names it registers with common subsystems (e.g. JACK client names). This ensures that multiple
  240. instances of the same application can be restored in any order without scrambling the JACK
  241. connections or causing other conflicts.
  242. The provided `client_id` will be a concatenation of the value of `application_name` sent by the
  243. client in its `announce` message and a unique identifier.
  244. Therefore, applications which create single JACK clients can use the value of `client_id` directly
  245. as their JACK client name.
  246. Applications which register multiple JACK clients (e.g. Carla or Non-Mixer) MUST PRE-PEND
  247. `client_id` value, followed by "/", to the client names they register with JACK and the application
  248. determined part MUST be unique for that (JACK) client.
  249. For example, Carla is a plugin-host that loads each plugin as JACK client.
  250. Suitable JACK client names are: `carla-jack-multi.nBAF/ZynAddSubFx` or `carla-jack-multi.nBAF/Helm`
  251. Please note that ZynAddSubFx and Helm are *not ports* but clients. Each of them can have any number
  252. of audio and midi ports below them.
  253. Note that this means that the application MUST NOT register with JACK (or any
  254. other subsystem requiring unique names) until it receives an `open` message from NSM. Likewise,
  255. applications with the `:switch:` capability should close their JACK clients and re-create them with
  256. using the new `client_id` (renaming JACK-clients is not possible, only ports).
  257. A response is REQUIRED as soon as the open operation has been completed. Ongoing progress MAY be
  258. indicated by sending messages to `/nsm/client/progress`.
  259. ===== Response
  260. The client MUST respond to the 'open' message with:
  261. [source%nowrap,OSC]
  262. ----
  263. /reply "/nsm/client/open" s:message
  264. ----
  265. Or
  266. [source%nowrap,OSC]
  267. ----
  268. /error "/nsm/client/open" i:error_code s:message
  269. ----
  270. .Response codes
  271. [options="header", stripes=even]
  272. |===
  273. |Code | Meaning
  274. |ERR | General Error
  275. |ERR_BAD_PROJECT | An existing project file was found to be corrupt
  276. |ERR_CREATE_FAILED | A new project could not be created
  277. |ERR_UNSAVED_CHANGES | Unsaved changes would be lost
  278. |ERR_NOT_NOW | Operation cannot be completed at this time
  279. |===
  280. ==== Save
  281. [source%nowrap,OSC]
  282. ----
  283. /nsm/client/save
  284. ----
  285. This message will only be delivered after a previous `open` message, and may be sent any number of
  286. times within the course of a session (including zero, if the user aborts the session).
  287. ===== Response
  288. [source%nowrap,OSC]
  289. ----
  290. /reply "/nsm/client/save" s:message
  291. ----
  292. Or
  293. [source%nowrap,OSC]
  294. ----
  295. /error "/nsm/client/save" i:error_code s:message
  296. ----
  297. .Response codes
  298. [options="header", stripes=even]
  299. |===
  300. |Code | Meaning
  301. |ERR | General Error
  302. |ERR_SAVE_FAILED | Project could not be saved
  303. |ERR_NOT_NOW | Operation cannot be completed at this time
  304. |===
  305. === Server to Client Informational Messages
  306. ==== Session is Loaded
  307. Accepting this message is optional. The intent is to signal to clients which may have some
  308. interdependence (say, peer to peer OSC connections) that the session is fully loaded and all their
  309. peers are available. Most clients will not need to act on this message. This message has no meaning
  310. when a session is being built or run; only when it is initially loaded. Clients who intend to act
  311. on this message MUST NOT do so by delaying initialization waiting for it.
  312. [source%nowrap,OSC]
  313. ----
  314. /nsm/client/session_is_loaded
  315. ----
  316. This message does not require a response.
  317. ==== Show Optional Gui
  318. If the client has specified the `optional-gui` capability, then it may receive this message from the
  319. server when the user wishes to change the visibility state of the GUI. It doesn't matter if the
  320. optional GUI is integrated with the program or if it is a separate program \(as is the case with
  321. SooperLooper\). When the GUI is hidden, there should be no window mapped and if the GUI is a
  322. separate program, it should be killed.
  323. [source%nowrap,OSC]
  324. ----
  325. /nsm/client/show_optional_gui
  326. ----
  327. [source%nowrap,OSC]
  328. ----
  329. /nsm/client/hide_optional_gui
  330. ----
  331. This message does not require a response.
  332. === Client to Server Informational Messages
  333. ==== Optional GUI
  334. If the client has specified the `optional-gui` capability, then it MUST send this message whenever
  335. the state of visibility of the optional GUI has changed. It also MUST send this message after its
  336. announce message to indicate the initial visibility state of the optional GUI.
  337. The client SHOULD always start hidden, if not saved as visible. That implies the first load, after
  338. adding to the session, SHOULD always be hidden.
  339. It is the responsibility of the client to remember the visibility state of its GUI across session
  340. loads.
  341. [source%nowrap,OSC]
  342. ----
  343. /nsm/client/gui_is_hidden
  344. ----
  345. [source%nowrap,OSC]
  346. ----
  347. /nsm/client/gui_is_shown
  348. ----
  349. No response will be delivered.
  350. ==== Progress
  351. [source%nowrap,OSC]
  352. ----
  353. /nsm/client/progress f:progress
  354. ----
  355. For potentially time-consuming operations, such as `save` and `open`, progress updates may be
  356. indicated throughout the duration by sending a floating point value between 0.0 and 1.0, 1.0
  357. indicating completion, to the NSM server.
  358. The server will not send a response to these messages, but will relay the information to the user.
  359. Note that even when using the `progress` feature, the final response to the `save` or `open`
  360. message is still REQUIRED.
  361. Clients which intend to send progress messages MUST include `:progress:` in their `announce`
  362. capability string.
  363. ==== Dirtiness
  364. [source%nowrap,OSC]
  365. ----
  366. /nsm/client/is_dirty
  367. ----
  368. [source%nowrap,OSC]
  369. ----
  370. /nsm/client/is_clean
  371. ----
  372. Some clients may be able to inform the server when they have unsaved changes pending. Such clients
  373. may optionally send `is_dirty` and `is_clean` messages.
  374. Clients which have and use this capability MUST include `:dirty:` in their `announce` capability string.
  375. ==== Status Messsages
  376. [source%nowrap,OSC]
  377. ----
  378. /nsm/client/message i:priority s:message
  379. ----
  380. Clients may send miscellaneous status updates to the server for possible display to the user. This
  381. may simply be chatter that is normally written to the console. `priority` MUST be a number from 0
  382. to 3, 3 being the most important.
  383. Clients which have and use this capability MUST include `:message:` in their `announce` capability
  384. string.
  385. === Error Code Definitions
  386. .Error Code Definitions
  387. [options="header", stripes=even]
  388. |===
  389. |Symbolic Name | Integer Value
  390. |ERR_GENERAL | -1
  392. |ERR_BLACKLISTED | -3
  393. |ERR_LAUNCH_FAILED | -4
  394. |ERR_NO_SUCH_FILE | -5
  395. |ERR_NO_SESSION_OPEN | -6
  397. |ERR_NOT_NOW | -8
  398. |ERR_BAD_PROJECT | -9
  399. |ERR_CREATE_FAILED | -10
  400. |===
  401. === Client to Server Control
  402. If the server publishes the `:server-control:` capability, then clients can also initiate action by
  403. the server. For example, a client might implement a 'Save All' option which sends a
  404. `/nsm/server/save` message to the server, rather than requiring the user to switch to the session
  405. management interface to effect the save.
  406. === Server Control API
  407. The session manager not only manages clients via OSC, but it is itself controlled via OSC messages.
  408. The server responds to the following messages.
  409. All of the following messages will be responded to, at the sender's address, with one of the two
  410. following messages:
  411. [source%nowrap,OSC]
  412. ----
  413. /reply s:path s:message
  414. ----
  415. [source%nowrap,OSC]
  416. ----
  417. /error s:path i:error_code s:message
  418. ----
  419. The first parameter of the reply is the path to the message being replied to. The `/error` reply
  420. includes an integer error code (non-zero indicates error). `message` will be a description of the
  421. error.
  422. The possible errors are:
  423. .Responses
  424. [options="header", stripes=even]
  425. |===
  426. |Code |Meaning
  427. |ERR_GENERAL | General Error
  428. |ERR_LAUNCH_FAILED | Launch failed
  429. |ERR_NO_SUCH_FILE | No such file
  430. |ERR_NO_SESSION | No session is open
  431. |ERR_UNSAVED_CHANGES | Unsaved changes would be lost
  432. |===
  433. * `/nsm/server/add s:executable_name`
  434. ** Adds a client to the current session.
  435. * `/nsm/server/save`
  436. ** Saves the current session.
  437. * `/nsm/server/open s:project_name`
  438. ** Saves the current session and loads a new session.
  439. * `/nsm/server/new s:project_name`
  440. ** Saves the current session and creates a new session.
  441. * `/nsm/server/duplicate s:new_project`
  442. ** Saves and closes the current session, makes a copy, and opens it.
  443. * `/nsm/server/close`
  444. ** Saves and closes the current session.
  445. * `/nsm/server/abort`
  446. ** Closes the current session WITHOUT SAVING
  447. * `/nsm/server/quit`
  448. ** Saves and closes the current session and terminates the server.
  449. * `/nsm/server/list`
  450. ** Lists available projects. One `/reply` message will be sent for each existing project.
  451. ** Afer listing the last session one final `/reply` with `/nsm/server/list, ""` will be send. That is an empty string.
  452. ==== Client to Client Communication
  453. If the server includes `:broadcast:` in its capability string, then clients may send broadcast
  454. messages to each other through the NSM server. Clients may send messages to the server at the path
  455. `/nsm/server/broadcast`.
  456. The format of this message is as follows:
  457. [source%nowrap,OSC]
  458. ----
  459. /nsm/server/broadcast s:path [arguments...]
  460. ----
  461. The message will then be relayed to all clients in the session at the path `path` (with the
  462. arguments shifted by one).
  463. For example the message:
  464. [source%nowrap,OSC]
  465. ----
  466. /nsm/server/broadcast /tempomap/update "0,120,4/4:12351234,240,4/4"
  467. ----
  468. Would broadcast the following message to all clients in the session (except for the sender), some
  469. of which might respond to the message by updating their own tempo maps.
  470. [source%nowrap,OSC]
  471. ----
  472. /tempomap/update "0,120,4/4:12351234,240,4/4"
  473. ----
  474. The Non programs use this feature to establish peer to peer OSC communication by symbolic names
  475. (client IDs) without having to remember the OSC URLs of peers across sessions.
  476. == API Versions and Behaviour Changes
  477. Here we will document all technical changes or differences in behaviour together with their API and
  478. project version numbers. The term "original" refers to Non Session Manager and "new" refers to New
  479. Session Manager.
  480. Version numbers follow link:[Semantic Versioning 2.0.0]
  481. .Semantic Versioning Scheme
  482. ```
  483. Given a version number MAJOR.MINOR.PATCH, increment the:
  484. MAJOR version when you make incompatible API changes,
  485. MINOR version when you add functionality in a backwards compatible manner, and
  486. PATCH version when you make backwards compatible bug fixes.
  487. ```
  488. .NSM Version Numbers
  489. [options="header", stripes=even]
  490. |===
  491. |Subject | Version
  492. |Non Session Manager at moment of fork | 1.2 (June 2020)
  493. |Non Session Manager API | 1.0 link:[NON nsmd.C]
  494. |Original API Document | 1.0 link:[]
  495. |New Session Manager | 1.4.0
  496. |New Session Manager API | 1.1.0 link:[NEW nsmd.cpp]
  497. |New API Document | 1.4.0 link:#[Here]
  498. |===
  499. === Guidelines
  500. The most important factor in decision making is to keep client compatibility at 100%.
  501. No client will ever receive an unrequested OSC message except those in API 1.0.0.
  502. Messages that drastically change existing `/nsm/client/` or `/nsm/server` behaviour require an
  503. inrecement to `API_VERSION_MAJOR`, which we want to avoid.
  504. `nsmd` checks if the clients `API_VERSION_MAJOR` is greater than its own and refuses the client
  506. All changes (that concern client/server behaviour) that increment `API_VERSION_MINOR` will be
  507. request-only or gated by new capabilities (e.g. `:optional-gui:`). `nsmd` will not send any
  508. messages if a capability was not sent by the client in <<Announce,`announce`>>. This includes
  509. mostly optional features about requesting extra information.
  510. New actions for server-control, for example a hypothetical `/nsm/server/save_as`, which would be
  511. triggered by the client and would only be *answered* by the server ("no unrequested message") will
  512. increment `API_VERSION_MINOR`.
  513. All changes that increment `API_VERSION_PATCH` will not have any effect on behaviour, except to
  514. fix clear problems, where "problem" is defined by having a different effect than described in this
  515. document, which includes technical problems such as crashes.
  516. All messages regarding GUI-communication that start with `/nsm/gui/...` were undocumented in API
  517. 1.0.0 and only used by `non-session-manager` / `nsm-legacy-gui`. Until properly documented in this
  518. document this part of the API is considered unstable and may change at any time without notice.
  519. However, when changing already existing messages and behaviour it MAY increment `API_VERSION_MINOR`
  520. or `API_VERSION_PATCH`. In that case it will appear in the list below.
  521. Last factor of compatibility is that any unknown message sent to `nsmd` will just print a warning
  522. message to stdout, but will otherwise be ignored. This secures a stable server, even when a client
  523. misbehaves and sends too-new messages outside of announced :capabilites:
  524. === Changes in API Version 1.1.0
  525. Rewritten API document without code changes to adapt to existing code or existing client behaviour:
  526. * Changed versioning scheme to Semantic Versioning with three positions Major.Minor.Patch
  527. * <<Quit or Exit>> SHOULD hide instead of exiting when :optional-gui: is supported and MAY not
  528. act on the quit through menu otherwise.
  529. * <<#server-to-client-control-messages-open,Open>>: Make clear that there are only certain
  530. possibilities for save paths. We added MUST because the rule was just implied before.
  531. * <<#server-to-client-control-messages-open,Open>>: Make clear that the delimiter for
  532. multi-jack clients is "/".
  533. * <<Optional GUI>> SHOULD start hidden, always after a fresh add to the session. After that saving
  534. the visibility state may override it for next time.
  535. * <<Progress>> MUST be announced in :capabilities: . Before there was a lower case "should",
  536. which means nothing. Parallel-examples in the specs cleary say that supporting optional features must be announced first.
  537. ** Same for <<Dirtiness>> and <<Status Messsages>>.
  538. * <<Status Messsages>> have priority numbers between 0 and 3, so they MUST send that.
  539. It was never an arbitrary value.
  540. Code changes:
  541. * <<Server Control API>>: `/nsm/server/list` chain of single OSC messages, one for each session,
  542. is now finalized with sending and empty string "" as session name. Previously this was just
  543. a symbolically irrelevant console message `"Done."`
  544. * Replies to `/nsm/server/save` etc. will now be sent back to the sender and not falsely to the last
  545. client who replied to `/nsm/client/save`. This alone would only require API_VERSION_PATCH
  546. increment, but we are already incrementing minor.
  547. * <<Server Control API>>: `/nsm/server/add` was replying with an undocumented error code on success.
  548. Instead, as this document always specificed, it now sends `"/reply", path, "Launched."`.
  549. Again, this would have been just API_VERSION_PATCH on its own.
  550. Undocumented (Unstable) `/nsm/gui` protocol
  551. * Send client status after a GUI attaches to running server. This
  552. was not happening before, but it was the intention. It was just broken in nsmd.cpp. This alone
  553. would only require API_VERSION_PATCH increment, but we are already incrementing minor.
  554. * Send label "launch error!" when a program is added (or loaded) that
  555. does not exist in $PATH. This requires no adaptation of any client, server or GUI because labels
  556. are arbitrary already and this is not meant for automatic parsing, but as user information.
  557. * `/nsm/gui/session/name` will now always send the same parameter format, regardless of how the session was opened:
  558. simple-session-name, relative session path with subdirs below session-root.
  559. * When a GUI announces itself to nsmd it will receive the absolute path to the session directory
  560. through the message `/nsm/gui/session/root`. This is not a new addition but was already in
  561. non-session-manager git.