diff --git a/docs/api/LICENSE b/docs/api/LICENSE new file mode 100644 index 0000000..fdb710b --- /dev/null +++ b/docs/api/LICENSE @@ -0,0 +1,65 @@ +Creative Commons + +Creative Commons Legal Code +Attribution-ShareAlike 2.5 + +https://creativecommons.org/licenses/by-sa/2.5/legalcode + +CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE. +License + +THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED. + +BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS. + +1. Definitions + +"Collective Work" means a work, such as a periodical issue, anthology or encyclopedia, in which the Work in its entirety in unmodified form, along with a number of other contributions, constituting separate and independent works in themselves, are assembled into a collective whole. A work that constitutes a Collective Work will not be considered a Derivative Work (as defined below) for the purposes of this License. +"Derivative Work" means a work based upon the Work or upon the Work and other pre-existing works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which the Work may be recast, transformed, or adapted, except that a work that constitutes a Collective Work will not be considered a Derivative Work for the purpose of this License. For the avoidance of doubt, where the Work is a musical composition or sound recording, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered a Derivative Work for the purpose of this License. +"Licensor" means the individual or entity that offers the Work under the terms of this License. +"Original Author" means the individual or entity who created the Work. +"Work" means the copyrightable work of authorship offered under the terms of this License. +"You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation. +"License Elements" means the following high-level license attributes as selected by Licensor and indicated in the title of this License: Attribution, ShareAlike. +2. Fair Use Rights. Nothing in this license is intended to reduce, limit, or restrict any rights arising from fair use, first sale or other limitations on the exclusive rights of the copyright owner under copyright law or other applicable laws. + +3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below: + +to reproduce the Work, to incorporate the Work into one or more Collective Works, and to reproduce the Work as incorporated in the Collective Works; +to create and reproduce Derivative Works; +to distribute copies or phonorecords of, display publicly, perform publicly, and perform publicly by means of a digital audio transmission the Work including as incorporated in Collective Works; +to distribute copies or phonorecords of, display publicly, perform publicly, and perform publicly by means of a digital audio transmission Derivative Works. +For the avoidance of doubt, where the work is a musical composition: + +Performance Royalties Under Blanket Licenses. Licensor waives the exclusive right to collect, whether individually or via a performance rights society (e.g. ASCAP, BMI, SESAC), royalties for the public performance or public digital performance (e.g. webcast) of the Work. +Mechanical Rights and Statutory Royalties. Licensor waives the exclusive right to collect, whether individually or via a music rights society or designated agent (e.g. Harry Fox Agency), royalties for any phonorecord You create from the Work ("cover version") and distribute, subject to the compulsory license created by 17 USC Section 115 of the US Copyright Act (or the equivalent in other jurisdictions). +Webcasting Rights and Statutory Royalties. For the avoidance of doubt, where the Work is a sound recording, Licensor waives the exclusive right to collect, whether individually or via a performance-rights society (e.g. SoundExchange), royalties for the public digital performance (e.g. webcast) of the Work, subject to the compulsory license created by 17 USC Section 114 of the US Copyright Act (or the equivalent in other jurisdictions). +The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. All rights not expressly granted by Licensor are hereby reserved. + +4. Restrictions.The license granted in Section 3 above is expressly made subject to and limited by the following restrictions: + +You may distribute, publicly display, publicly perform, or publicly digitally perform the Work only under the terms of this License, and You must include a copy of, or the Uniform Resource Identifier for, this License with every copy or phonorecord of the Work You distribute, publicly display, publicly perform, or publicly digitally perform. You may not offer or impose any terms on the Work that alter or restrict the terms of this License or the recipients' exercise of the rights granted hereunder. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties. You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. The above applies to the Work as incorporated in a Collective Work, but this does not require the Collective Work apart from the Work itself to be made subject to the terms of this License. If You create a Collective Work, upon notice from any Licensor You must, to the extent practicable, remove from the Collective Work any credit as required by clause 4(c), as requested. If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any credit as required by clause 4(c), as requested. +You may distribute, publicly display, publicly perform, or publicly digitally perform a Derivative Work only under the terms of this License, a later version of this License with the same License Elements as this License, or a Creative Commons iCommons license that contains the same License Elements as this License (e.g. Attribution-ShareAlike 2.5 Japan). You must include a copy of, or the Uniform Resource Identifier for, this License or other license specified in the previous sentence with every copy or phonorecord of each Derivative Work You distribute, publicly display, publicly perform, or publicly digitally perform. You may not offer or impose any terms on the Derivative Works that alter or restrict the terms of this License or the recipients' exercise of the rights granted hereunder, and You must keep intact all notices that refer to this License and to the disclaimer of warranties. You may not distribute, publicly display, publicly perform, or publicly digitally perform the Derivative Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. The above applies to the Derivative Work as incorporated in a Collective Work, but this does not require the Collective Work apart from the Derivative Work itself to be made subject to the terms of this License. +If you distribute, publicly display, publicly perform, or publicly digitally perform the Work or any Derivative Works or Collective Works, You must keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or (ii) if the Original Author and/or Licensor designate another party or parties (e.g. a sponsor institute, publishing entity, journal) for attribution in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; the title of the Work if supplied; to the extent reasonably practicable, the Uniform Resource Identifier, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and in the case of a Derivative Work, a credit identifying the use of the Work in the Derivative Work (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). Such credit may be implemented in any reasonable manner; provided, however, that in the case of a Derivative Work or Collective Work, at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit. +5. Representations, Warranties and Disclaimer + +UNLESS OTHERWISE AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE MATERIALS, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU. + +6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. + +7. Termination + +This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Derivative Works or Collective Works from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License. +Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above. +8. Miscellaneous + +Each time You distribute or publicly digitally perform the Work or a Collective Work, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License. +Each time You distribute or publicly digitally perform a Derivative Work, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License. +If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable. +No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent. +This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You. +Creative Commons is not a party to this License, and makes no warranty whatsoever in connection with the Work. Creative Commons will not be liable to You or any party on any legal theory for any damages whatsoever, including without limitation any general, special, incidental or consequential damages arising in connection to this license. Notwithstanding the foregoing two (2) sentences, if Creative Commons has expressly identified itself as the Licensor hereunder, it shall have all rights and obligations of Licensor. + +Except for the limited purpose of indicating to the public that the Work is licensed under the CCPL, neither party will use the trademark "Creative Commons" or any related trademark or logo of Creative Commons without the prior written consent of Creative Commons. Any permitted use will be in compliance with Creative Commons' then-current trademark usage guidelines, as may be published on its website or otherwise made available upon request from time to time. + +Creative Commons may be contacted at https://creativecommons.org/. diff --git a/docs/api/api.adoc b/docs/api/api.adoc new file mode 100644 index 0000000..2696fe9 --- /dev/null +++ b/docs/api/api.adoc @@ -0,0 +1,669 @@ +//// +This is not an "asciidoctor", not plain "asciidoc" document. +https://asciidoctor.org/docs/user-manual/ +//// + +//// +This documentation is licensed under the Creative Commons Attribution-ShareAlike 2.5 International License. +To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/2.5/legalcode or send a +letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. +A copy of the license has been provided in the file documentation/API/LICENSE. +//// + + +:authors: Jonathan Moore Liles +:email: +:revnumber: 1.2 +:revdate: 2013-04-06 + +:iconfont-remote!: +:!webfonts: + +:sectnums: +:sectnumlevels: 4 + +:toc: preamble +:toc-title: Table of Contents +:toclevels: 4 + + += Non Session Manager API + + +== 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.b + +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 <> 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) + + + +=== 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: + +[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 +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 +[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 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 +[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--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: + + +[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 (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 <>) 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 +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 + +[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 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: + +[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 +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 +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 +---- + +No response is message is required. + + + +==== Client to Server Informational Messages + +===== 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. + +[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 +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 + +[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 this capability should 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` 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 +[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 +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. + + + +===== 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. diff --git a/docs/api/index.html b/docs/api/index.html new file mode 100644 index 0000000..700234d --- /dev/null +++ b/docs/api/index.html @@ -0,0 +1,1386 @@ + + + + + + + + +Non Session Manager API + + + + +
+
+

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.b

+
+
+

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

+
+
+
+
+
+

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.

+
+ + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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

+
+
+
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:

+
+ + ++++ + + + + + + + + + + + + + + + + + + + + +
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—​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:

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

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 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: $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
+
+
+ + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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

+
+
+
+
1.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).

+
+
+
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

+
+
+
+
+

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

+
+
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 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 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

+ + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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

+
+
+

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:

+
+ + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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.

      +
      • +
    +
    +
    • +
+
+
+
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.

+
+
+
+
+
+
+
+ + + \ No newline at end of file diff --git a/docs/api/readme.txt b/docs/api/readme.txt new file mode 100644 index 0000000..382416e --- /dev/null +++ b/docs/api/readme.txt @@ -0,0 +1,18 @@ +The statements made here only concern the API document. All other documentation and help texts of +the "New Session Manager" are original works. + +This subdirectory "API" contains an adapted copy of http://non.tuxfamily.org/nsm/API.html, which +was released by Jonathan Moore Liles under the title "Non Session Management +API Version 1." + +It was published on the the NON-Website on 2013-04-06 with git commit +d7cf8955b8557ccc56d108425a2c61b0e1ac73f4 under the Creative Commons By-Sa License 2.5, as was the +whole website (see website footer). For a full copy of the license please see the attached file +LICENSE. + +This adaption and all changes are licensed under CC-By-Sa 2.5 as well. The original work was copied +from the NON-website by hand in 2020-07 by Nils Hilbricht. + +Initial git commit on 2020-07-06 is the unaltered content by Jonathan Moore Liles, not counting +layout changes because the document format changed. All subsequent changes and authors can be +reviewed by git log. diff --git a/docs/release-checklist.txt b/docs/release-checklist.txt new file mode 100644 index 0000000..7329882 --- /dev/null +++ b/docs/release-checklist.txt @@ -0,0 +1,13 @@ +This is an internal reminder what to check and change before a release. + +/documentation/API/api.adoc + :revnumber: + :revdate: + +Version number in /meson.build (one occurence) +Version number and changes in /CHANGELOG +Regenerate API and Website html to update the date in their footer + +We do not change the copyright date in file license-headers. That is not required by law and only +exist to mark to year of the fork. In the future it might be removed completely. +