The server actually sends :server-control: not :server_control:. Reflect that in the documentation
Nils Hilbricht
parent
f572e331ee
commit
80ed58c9e6
|
|
@ -120,7 +120,7 @@ This option may empty/reset the current file or project (possibly after user con
|
|||
</p>
|
||||
<h4 id="n:1.1.1.2.">1.1.1.2. Open</h4>
|
||||
<p>
|
||||
This option <b>MUST</b> be disabled.
|
||||
This option <b>MUST</b> be disabled.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
|
|
@ -228,7 +228,7 @@ Presently, the server <tt>capabilities</tt> are:
|
|||
<strong>Fig. 1.2.</strong> Available Server Capabilities
|
||||
</caption>
|
||||
<tr><th>Name</th><th>Description</th></tr>
|
||||
<tr><td>server_control</td><td>client-to-server control</td></tr>
|
||||
<tr><td>server-control</td><td>client-to-server control</td></tr>
|
||||
<tr><td>broadcast</td><td>server responds to /nsm/server/broadcast message</td></tr>
|
||||
<tr><td>optional-gui</td><td>server responds to optional-gui messages--if this capability is not present then clients with optional-guis MUST always keep them visible</td></tr>
|
||||
</table></div></center>
|
||||
|
|
@ -397,7 +397,7 @@ This message does not require a response.
|
|||
If the client has specified the <tt>optional-gui</tt> 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.
|
||||
</p>
|
||||
<div class="fig example"><table width=100%><tr><td><pre>
|
||||
/nsm/client/show_optional_gui
|
||||
/nsm/client/show_optional_gui
|
||||
</pre></td></tr>
|
||||
</table></div>
|
||||
<div class="fig example"><table width=100%><tr><td><pre>
|
||||
|
|
@ -456,7 +456,7 @@ Clients which intend to send <tt>progress</tt> messages should include <tt>:prog
|
|||
</pre></td></tr>
|
||||
</table></div>
|
||||
<p>
|
||||
Some clients may be able to inform the server when they have unsaved changes pending. Such clients may optionally send <tt>is_dirty</tt> and <tt>is_clean</tt> messages.
|
||||
Some clients may be able to inform the server when they have unsaved changes pending. Such clients may optionally send <tt>is_dirty</tt> and <tt>is_clean</tt> messages.
|
||||
</p>
|
||||
<p>
|
||||
Clients which have this capability should include <tt>:dirty:</tt> in their <tt>announce</tt> capability string.
|
||||
|
|
@ -491,7 +491,7 @@ Clients which have this capability should include <tt>:message:</tt> in their <t
|
|||
</table></div></center>
|
||||
<h3 id="n:1.2.6.">1.2.6. Client to Server Control</h3>
|
||||
<p>
|
||||
If the server publishes the <tt>:server_control:</tt> capability, then clients can also initiate action by the server. For example, a client might implement a 'Save All' option which sends a <tt>/nsm/server/save</tt> message to the server, rather than requiring the user to switch to the session management interface to effect the save.
|
||||
If the server publishes the <tt>:server-control:</tt> capability, then clients can also initiate action by the server. For example, a client might implement a 'Save All' option which sends a <tt>/nsm/server/save</tt> message to the server, rather than requiring the user to switch to the session management interface to effect the save.
|
||||
</p>
|
||||
<h3 id="n:1.2.7.">1.2.7. Server Control API</h3>
|
||||
<p>
|
||||
|
|
@ -565,7 +565,7 @@ Saves and closes the current session.
|
|||
<dt><em>/nsm/server/abort</em></dt>
|
||||
</dl>
|
||||
<p>
|
||||
Closes the current session <b>WITHOUT SAVING</b>
|
||||
Closes the current session <b>WITHOUT SAVING</b>
|
||||
</p>
|
||||
<dl>
|
||||
<dt><em>/nsm/server/quit</em></dt>
|
||||
|
|
@ -591,7 +591,7 @@ The format of this message is as follows:
|
|||
</pre></td></tr>
|
||||
</table></div>
|
||||
<p>
|
||||
The message will then be relayed to all clients in the session at the path <tt>path</tt> (with the arguments shifted by one).
|
||||
The message will then be relayed to all clients in the session at the path <tt>path</tt> (with the arguments shifted by one).
|
||||
</p>
|
||||
<p>
|
||||
For example the message:
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
|
||||
! title Non Session Management API
|
||||
! author Jonathan Moore Liles #(email,male@tuxfamily.org)
|
||||
! revision Version 1.2
|
||||
! extra #(image,logo,icon.png)
|
||||
! title Non Session Management API
|
||||
! author Jonathan Moore Liles #(email,male@tuxfamily.org)
|
||||
! revision Version 1.2
|
||||
! extra #(image,logo,icon.png)
|
||||
|
||||
-- Table Of Contents
|
||||
|
||||
|
|
@ -24,7 +24,7 @@
|
|||
(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.
|
||||
|
|
@ -56,8 +56,8 @@
|
|||
The following sub-sections describe how these options should behave when
|
||||
the application is part of an NSM session. These rules only apply
|
||||
when session management is active (that is, after the `announce`
|
||||
handshake described in the #(ref,Non Session Management API::NSM OSC Protocol) section).
|
||||
|
||||
handshake described in the #(ref,Non Session Management API::NSM OSC Protocol) section).
|
||||
|
||||
In order to provide a consistent and predictable user experience, it
|
||||
is critically important for applications to adhere to these
|
||||
guidelines.
|
||||
|
|
@ -72,7 +72,7 @@
|
|||
|
||||
:::: Open
|
||||
|
||||
This option *MUST* be disabled.
|
||||
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
|
||||
|
|
@ -96,7 +96,7 @@
|
|||
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.
|
||||
|
||||
|
|
@ -190,7 +190,7 @@
|
|||
[[ 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
|
||||
[[ message, client can send textual status updates
|
||||
[[ optional-gui, client has an optional GUI
|
||||
|
||||
:::: Response
|
||||
|
|
@ -213,7 +213,7 @@
|
|||
|
||||
// Available Server Capabilities
|
||||
[[ Name, Description
|
||||
[[ server_control, client-to-server control
|
||||
[[ 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
|
||||
|
||||
|
|
@ -265,7 +265,7 @@
|
|||
application will receive this signal soon after having responded to
|
||||
a `save` message.
|
||||
|
||||
:::: Open
|
||||
:::: Open
|
||||
|
||||
> /nsm/client/open s:path_to_instance_specific_project s:display_name s:client_id
|
||||
|
||||
|
|
@ -365,7 +365,7 @@
|
|||
established in the 'open' message. *UNDER NO CIRCUMSTANCES* should a
|
||||
dialog be displayed to the user (giving a choice of where to save,
|
||||
etc.)
|
||||
|
||||
|
||||
However, if the client is incapable of saving at the specific moment
|
||||
without disturbing the user (e.g. a JACK client that can't save
|
||||
while the transport is rolling without causing massive XRUNS), then
|
||||
|
|
@ -393,7 +393,7 @@
|
|||
::: 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
|
||||
|
|
@ -417,7 +417,7 @@
|
|||
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/show_optional_gui
|
||||
|
||||
> /nsm/client/hide_optional_gui
|
||||
|
||||
|
|
@ -475,7 +475,7 @@
|
|||
|
||||
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.
|
||||
messages.
|
||||
|
||||
Clients which have this capability should include `:dirty:` in their
|
||||
`announce` capability string.
|
||||
|
|
@ -509,7 +509,7 @@
|
|||
|
||||
::: Client to Server Control
|
||||
|
||||
If the server publishes the `:server\_control:` capability, then
|
||||
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
|
||||
|
|
@ -528,7 +528,7 @@
|
|||
> /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
|
||||
|
|
@ -570,13 +570,13 @@
|
|||
|
||||
= /nsm/server/abort
|
||||
|
||||
Closes the current session *WITHOUT SAVING*
|
||||
Closes the current session *WITHOUT SAVING*
|
||||
|
||||
= /nsm/server/quit
|
||||
|
||||
Saves and closes the current session and terminates the server.
|
||||
|
||||
= /nsm/server/list
|
||||
= /nsm/server/list
|
||||
|
||||
Lists available projects. One `\/reply` message will be sent for each existing project.
|
||||
|
||||
|
|
@ -585,7 +585,7 @@
|
|||
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`.
|
||||
|
||||
|
|
@ -594,7 +594,7 @@
|
|||
> /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).
|
||||
the path `path` (with the arguments shifted by one).
|
||||
|
||||
For example the message:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue