mirrors
/
non
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update documentation.

pull/3/head
Jonathan Moore Liles 2012-02-26 02:51:33 -08:00
parent 388796a1c4
commit 9de99e2380
16 changed files with 1264 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
mixer/doc/MANUAL.html
View File

@ -153,20 +153,20 @@ The input parameters of all modules are controllable via OSC, regardless of whet
The format of the automatically generated OSC path names is as follows:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/mixer/strip/[STRIP_NAME]/control/[MODULE_NAME]/[PARAMETER_NAME]
/strip/[STRIP_NAME]/[MODULE_NAME]/[PARAMETER_NAME]
</pre></td></tr>
</table></div>
<p>
The UDP port that the OSC server binds to can be set by providing the <tt>--osc-port</tt> command-line option. Without this option, a random port will be bound automatically (the exact OSC URL will always be printed to the console as a line beginning with "OSC: ").
</p>
<p>
The default path accepts a float value between 0.0 and 1.0 (a Control Voltage) which will be scaled to the allowable range of the control.
The default path accepts a float value between 0.0 and 1.0 (a Control Voltage like signal) which will be automatically scaled to the allowable range of the control.
</p>
<p>
A path ending in /unscaled is also available, which accepts exact values, which will be clamped to the allowable range. For example:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/mixer/strip/[STRIP_NAME]/control/[MODULE_NAME]/[PARAMETER_NAME]/unscaled
/strip/[STRIP_NAME]/[MODULE_NAME]/[PARAMETER_NAME]/unscaled
</pre></td></tr>
</table></div>
<p>
@ -180,7 +180,7 @@ If same module/plugin is used twice in a signal chain (e.g. multiple Gain stages
For the second instance of the Gain module on the strip named 'Foo'.
</p>
<p>
For each OSC parameter change message received, a reply will be sent to the same path at the sender with the new value as the only parameter. Changes to the control value initatied in the GUI will <b>not</b> generate any OSC messages.
Non-DAW accesses these same signals via a more advanced signal routing layer on top of OSC. Any module parameter is easily controlled via Control Sequences in Non-DAW without the need to specify an OSC URL.
</p>
<h6 id="n:1.1.2.3.1.2.">1.1.2.3.1.2. Manipulation</h6>
<p>
@ -256,6 +256,14 @@ Control Voltages, on the other hand, provide a simple 1:1 source to sink relatio
git clone git://fuzzle.org/jm2cv.git
</pre></td></tr>
</table></div>
<div class=admonition>
<table width=100%>
<tr><td>NOTE:
The use of Control Signals (OSC) should be preferred for types
of parameter automation, as LADSPA plugins are incapable of
processing Control Voltage signals at full resolution anyway.
</td></table>
</div>
<h3 id="n:1.1.3.">1.1.3. Projects</h3>
<p>
A Non-Mixer project is a directory where Non-Mixer keeps the strip settings, project specific settings, and some meta-data. A project is completely self-contained. You can rename a project as simply as:

20
mixer/doc/MANUAL.mu
View File

@ -118,7 +118,7 @@
The format of the automatically generated OSC path names is as follows:
> /mixer/strip/[STRIP_NAME]/control/[MODULE_NAME]/[PARAMETER_NAME]
> /strip/[STRIP_NAME]/[MODULE_NAME]/[PARAMETER_NAME]
The UDP port that the OSC server binds to can be set by providing
the `--osc-port` command-line option. Without this option, a random
@ -126,12 +126,13 @@
printed to the console as a line beginning with "OSC: ").
The default path accepts a float value between 0.0 and 1.0 (a
Control Voltage) which will be scaled to the allowable range of the control.
Control Voltage like signal) which will be automatically scaled to
the allowable range of the control.
A path ending in \/unscaled is also available, which accepts exact values,
which will be clamped to the allowable range. For example:
> /mixer/strip/[STRIP_NAME]/control/[MODULE_NAME]/[PARAMETER_NAME]/unscaled
> /strip/[STRIP_NAME]/[MODULE_NAME]/[PARAMETER_NAME]/unscaled
If same module\/plugin is used twice in a signal chain
(e.g. multiple Gain stages), then a position dependent sequence number
@ -142,10 +143,10 @@
For the second instance of the Gain module on the strip named 'Foo'.
For each OSC parameter change message received, a reply will be sent
to the same path at the sender with the new value as the only
parameter. Changes to the control value initatied in the GUI will
*not* generate any OSC messages.
Non-DAW accesses these same signals via a more advanced signal
routing layer on top of OSC. Any module parameter is easily
controlled via Control Sequences in Non-DAW without the need to
specify an OSC URL.
:::::: Manipulation
@ -235,6 +236,11 @@
> git clone git://fuzzle.org/jm2cv.git
{ NOTE:
{ The use of Control Signals (OSC) should be preferred for types
{ of parameter automation, as LADSPA plugins are incapable of
{ processing Control Voltage signals at full resolution anyway.
::: Projects
A Non-Mixer project is a directory where Non-Mixer keeps the strip

11
mixer/doc/OVERVIEW.html
View File

@ -51,12 +51,15 @@ February 1, 2010<br>
</ul></ul><hr></div>
<h1 id="n:1.">1. Overview</h1>
<center><div class="fig image"><table border=1>
<tr><td><img src="non-mixer-complex.png" alt="fig. "></td></tr>
</table></div></center>
<h2 id="n:1.1.">1.1. Description</h2>
<p>
The Non Mixer is a powerful, reliable and fast modular Digital Audio Mixer, released under the GNU General Public License (GPL). It utilizes the JACK Audio Connection Kit for inter-application audio I/O and the FLTK GUI toolkit for a fast and lightweight user interface.
</p>
<p>
Please see the <a class=ext href="MANUAL.html">Manual</a> for more information.
Please see the <a class=ext href="MANUAL.html">Manual</a> for more information (and lots of screenshots).
</p>
<h2 id="n:1.2.">1.2. Why write another one?</h2>
<p>
@ -91,7 +94,7 @@ Since the Mixer is an entirely separate unit, you may use any JACK capable mixer
The mixer's design is modular, with all DSP occurring in discrete modules. One module hosts LADSPA plugins and the mixer is capable of receiving control (automation) data for any module parameter from Non-DAW (or another program) via JACK.
</p>
<p>
Control data is expressed as Control Voltage (CV).
Control data is expressed either as Control Voltage (CV) or Control Signals.
</p>
<h3 id="n:1.3.2.">1.3.2. Modular Signal Processing</h3>
<p>
@ -115,7 +118,7 @@ There is no limit imposed by Non Mixer on the total number of strips or Mixer in
</p>
<h3 id="n:1.3.7.">1.3.7. Automation</h3>
<p>
Any module parameter may be bound to a <i>control</i>. The control may be controlled via the GUI, or externally via a Control Voltage signal, such as is output by a Non-DAW control sequence.
Any module parameter may be bound to a <i>control</i>. The control may be controlled via the GUI, or externally via a Control Voltage signal, such as is output by a Non-DAW control sequence. All module parameters are alterable via OSC messages, regardless of whether or not they have <i>controls</i> defined.
</p>
<h1 id="u:1.">What does freedom have to do with this software?</h1>
<p>
@ -155,6 +158,8 @@ The following libraries are required to build Non DAW and Non Mixer
<ul><li><span>FLTK >= 1.1.7 (with `fluid`)</span>
<li><span>JACK >= 0.103.0</span>
<li><span>liblrdf >= 0.1.0</span>
<li><span>liblo >= 0.26</span>
<li><span>libsigc++ >= 2.0.0</span>
</ul><h1 id="u:5.">Community</h1>
<p>
Feel free to drop by the <tt>#non</tt> channel on irc.freenode.net.

13
mixer/doc/OVERVIEW.mu
View File

@ -8,6 +8,8 @@
: Overview
< non-mixer-complex.png
:: Description
The Non Mixer is a powerful, reliable and fast modular Digital Audio
@ -16,7 +18,8 @@
I\/O and the FLTK GUI toolkit for a fast and lightweight user
interface.
Please see the #(url,MANUAL.html,Manual) for more information.
Please see the #(url,MANUAL.html,Manual) for more information (and
lots of screenshots).
:: Why write another one?
@ -76,7 +79,8 @@
receiving control (automation) data for any module parameter from
Non-DAW (or another program) via JACK.
Control data is expressed as Control Voltage (CV).
Control data is expressed either as Control Voltage (CV) or Control
Signals.
::: Modular Signal Processing
@ -124,6 +128,9 @@
Any module parameter may be bound to a /control/. The control may be
controlled via the GUI, or externally via a Control Voltage signal,
such as is output by a Non-DAW control sequence.
All module parameters are alterable via OSC messages, regardless of
whether or not they have /controls/ defined.
; What does freedom have to do with this software?
@ -174,6 +181,8 @@
* FLTK >= 1.1.7 (with `fluid`)
* JACK >= 0.103.0
* liblrdf >= 0.1.0
* liblo >= 0.26
* libsigc++ >= 2.0.0
; Community

542
session/doc/API.html Normal file
View File

@ -0,0 +1,542 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta name="generator" content="Generated by MUP v3.5">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link type="text/css" rel="stylesheet" href="mup.css">
<title>Non Session Management API</title>
</head>
<body>
<div id=cover>
<h1>Non Session Management API</h1>
<h3></h3>
<address>
Jonathan Moore Liles <a href="mailto:male@tuxfamily.org">&lt;male@tuxfamily.org&gt;</a><br>
August 1, 2010<br>
Version 0.8
</address><hr></div>
<div id=body>
<div id=toc>
<h1 id=toc>Table Of Contents</h1>
<ul>
<li><a href="#n:1.">1. Non Session Management API</a>
<ul><li><a href="#n:1.1.">1.1. Client Behavior Under Session Management</a>
<ul><li><a href="#n:1.1.1.">1.1.1. New</a>
<li><a href="#n:1.1.2.">1.1.2. Open</a>
<li><a href="#n:1.1.3.">1.1.3. Save</a>
<li><a href="#n:1.1.4.">1.1.4. Save As</a>
<li><a href="#n:1.1.5.">1.1.5. Close (as distinguished from Quit or Exit)</a>
<li><a href="#n:1.1.6.">1.1.6. Quit or Exit</a>
</ul><li><a href="#n:1.2.">1.2. NSM OSC Protocol</a>
<ul><li><a href="#n:1.2.1.">1.2.1. Establishing a Connection</a>
<ul><li><a href="#n:1.2.1.1.">1.2.1.1. Announce</a>
<li><a href="#n:1.2.1.2.">1.2.1.2. Response</a>
</ul><li><a href="#n:1.2.2.">1.2.2. Server to Client Control Messages</a>
<ul><li><a href="#n:1.2.2.1.">1.2.2.1. Quit</a>
<li><a href="#n:1.2.2.2.">1.2.2.2. Open </a>
<ul><li><a href="#n:1.2.2.2.1.">1.2.2.2.1. Response</a>
</ul><li><a href="#n:1.2.2.3.">1.2.2.3. Save</a>
<ul><li><a href="#n:1.2.2.3.1.">1.2.2.3.1. Response</a>
</ul></ul><li><a href="#n:1.2.3.">1.2.3. Server to Client Informational Messages</a>
<ul><li><a href="#n:1.2.3.1.">1.2.3.1. Session is Loaded</a>
</ul><li><a href="#n:1.2.4.">1.2.4. Client to Server Informational Messages</a>
<ul><li><a href="#n:1.2.4.1.">1.2.4.1. Progress</a>
<li><a href="#n:1.2.4.2.">1.2.4.2. Dirtiness</a>
<li><a href="#n:1.2.4.3.">1.2.4.3. Status Messages</a>
</ul><li><a href="#n:1.2.5.">1.2.5. Error Code Definitions</a>
<li><a href="#n:1.2.6.">1.2.6. Client to Server Control</a>
<li><a href="#n:1.2.7.">1.2.7. Server Control API</a>
<ul><li><a href="#n:1.2.7.1.">1.2.7.1. Client to Client Communication</a>
</ul></ul></ul></ul></ul><hr></div>
<h1 id="n:1.">1. Non Session Management API</h1>
<p>
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.
</p>
<p>
The API comprises a simple Open Sound Control (OSC) based protocol, along with some behavioral guidelines, which can easily be implemented by various applications.
</p>
<p>
The Non project contains an program called <tt>nsmd</tt> which is an implementation of the server side of the NSM API. <tt>nsmd</tt> is controlled by the <tt>non-session-manager</tt> 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 <tt>liblo</tt> (the OSC library), which several Linux audio applications already link to or plan to link to in the future.
</p>
<p>
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.
</p>
<p>
You <b>WILL</b> 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.
</p>
<h2 id="n:1.1.">1.1. Client Behavior Under Session Management</h2>
<p>
Most graphical applications make available to the user a common set of file operations, typically presented under a File or Project menu.
</p>
<p>
These are: New, Open, Save, Save As, Close and Quit or Exit.
</p>
<p>
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 <tt>announce</tt> handshake described in the <a class=int href="#"></a> section). In order to provide a consistent and predictable user experience, it is critically important for applications to adhere to these guidelines.
</p>
<h3 id="n:1.1.1.">1.1.1. New</h3>
<p>
This option may empty/reset the current file or project (possibly after user confirmation). <b>UNDER NO CIRCUMSTANCES</b> should it allow the user to create a new project/file in another location.
</p>
<h3 id="n:1.1.2.">1.1.2. Open</h3>
<p>
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.
</p>
<h3 id="n:1.1.3.">1.1.3. Save</h3>
<p>
This option should behave as normal, saving the current file/project as established by the NSM <tt>open</tt> message.
</p>
<p>
<b>UNDER NO CIRCUMSTANCES</b> should this option present the user with a choice of where to save the file.
</p>
<h3 id="n:1.1.4.">1.1.4. Save As</h3>
<p>
This option <b>MUST</b> be disabled.
</p>
<p>
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.
</p>
<h3 id="n:1.1.5.">1.1.5. Close (as distinguished from Quit or Exit)</h3>
<p>
This option <b>MUST</b> be disabled unless its meaning is to disconnect the application from session management.
</p>
<h3 id="n:1.1.6.">1.1.6. Quit or Exit</h3>
<p>
This option may behave as normal (even possibly asking the user to confirm exiting).
</p>
<h2 id="n:1.2.">1.2. NSM OSC Protocol</h2>
<p>
All message parameters are <b>REQUIRED</b>. All messages <b>MUST</b> be sent from the same socket as the <tt>announce</tt> message, using the <tt>lo_send_from</tt> method of liblo or its equivalent, as the server uses the return addresses to distinguish between clients.
</p>
<p>
Clients <b>MUST</b> create thier OSC servers using the same protocol (UDP,TCP) as found in <tt>NSM_URL</tt>. liblo is lacking a robust TCP implementation at the time of writing, but in the future it may be useful.
</p>
<h3 id="n:1.2.1.">1.2.1. Establishing a Connection</h3>
<h4 id="n:1.2.1.1.">1.2.1.1. Announce</h4>
<p>
At launch, the client <b>MUST</b> check the environment for the value of <tt>NSM_URL</tt>. If present, the client <b>MUST</b> send the following message to the provided address as soon as it is ready to respond to the <tt>/nsm/client/open</tt> event:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/server/announce s:application_name s:capabilities s:executable_name i:api_version_major i:api_version_minor i:pid
</pre></td></tr>
</table></div>
<p>
If <tt>NSM_URL</tt> is undefined, invalid, or unreachable, then the client should proceed assuming that session management is unavailable.
</p>
<p>
<tt>api_version_major</tt> and <tt>api_version_minor</tt> must be the two parts of the version number of the NSM API as defined by this document.
</p>
<p>
Note that if the application intends to register JACK clients, <tt>application_name</tt> <b>MUST</b> be the same as the name that would normally by passed to <tt>jack_client_open</tt>. For example, Non-Mixer sends "Non-Mixer" as its <tt>application_name</tt>. Applications <b>MUST NOT</b> register their JACK clients until receiving an <tt>open</tt> message; the <tt>open</tt> 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 <tt>announce</tt> reply and subsequent <tt>open</tt> message.
</p>
<p>
<tt>capabilities</tt> <b>MUST</b> be a string containing a colon separated list of the special capabilities the client possesses. e.g. ":dirty:switch:progress:"
</p>
<center><div class="fig table"><table id="Fig.1.1" border=1>
<caption>
<strong>Fig. 1.1.</strong> Available Client Capabilities
</caption>
<tr><th>Name</th><th>Description</th></tr>
<tr><td>switch</td><td>client is capable of responding to multiple `open` messages without restarting</td></tr>
<tr><td>dirty</td><td>client knows when it has unsaved changes</td></tr>
<tr><td>progress</td><td>client can send progress updates during time-consuming operations</td></tr>
<tr><td>message</td><td>client can send textual status updates </td></tr>
</table></div></center>
<h4 id="n:1.2.1.2.">1.2.1.2. Response</h4>
<p>
The server will respond to the client's <tt>announce</tt> message with the following message:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/reply "/nsm/server/announce" s:message s:name_of_session_manager s:capabilities
</pre></td></tr>
</table></div>
<p>
<tt>message</tt> is a welcome message.
</p>
<p>
The value of <tt>name_of_session_manager</tt> 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.
</p>
<p>
<tt>capabilities</tt> will be a string containing a colon separated list of special server capabilities.
</p>
<p>
Presently, the server <tt>capabilities</tt> are:
</p>
<center><div class="fig table"><table id="Fig.1.2" border=1>
<caption>
<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>broadcast</td><td>server responds to /nsm/server/broadcast message</td></tr>
</table></div></center>
<p>
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.
</p>
<p>
If there is an error, a reply of the following form will be sent to the client:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/error "/nsm/server/announce" i:error_code s:error_message
</pre></td></tr>
</table></div>
<p>
The following table defines possible values of <tt>error_code</tt>:
</p>
<center><div class="fig table"><table id="Fig.1.3" border=1>
<caption>
<strong>Fig. 1.3.</strong> Response codes
</caption>
<tr><th>Code</th><th>Meaning</th></tr>
<tr><td>ERR_GENERAL</td><td>General Error</td></tr>
<tr><td>ERR_INCOMPATIBLE_API</td><td>Incompatible API version</td></tr>
<tr><td>ERR_BLACKLISTED</td><td>Client has been blacklisted.</td></tr>
</table></div></center>
<h3 id="n:1.2.2.">1.2.2. Server to Client Control Messages</h3>
<p>
Compliant clients <b>MUST</b> accept the client control messages described in this section. All client control messages <b>REQUIRE</b> a response. Responses <b>MUST</b> be delivered back to the sender (NSM) from the same socket used by the client in its <tt>announce</tt> message (by using <tt>lo_send_from</tt>) <b>AFTER</b> the action has been completed or if an error is encountered. The required response is described in the subsection for each message.
</p>
<p>
If there is an error and the action cannot be completed, then <tt>error_code</tt> <b>MUST</b> be set to a valid error code (see <a href="#Fig."></a>) and <tt>message</tt> to a string describing the problem (suitable for display to the user).
</p>
<p>
The reply can take one of the following two forms, where <tt>path</tt> <b>MUST</b> be the path of the message being replied to (e.g. "<i>nsm/client/save"</i>:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/reply s:path s:message
</pre></td></tr>
</table></div>
<div class="fig example"><table width=100%><tr><td><pre>
/error s:path i:error_code s:message
</pre></td></tr>
</table></div>
<h4 id="n:1.2.2.1.">1.2.2.1. Quit</h4>
<p>
There is no message for this. Clients will receive the Unix SIGTERM signal and <b>MUST</b> close cleanly <b>IMMEDIATELY</b>, 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 <tt>save</tt> message.
</p>
<h4 id="n:1.2.2.2.">1.2.2.2. Open </h4>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/client/open s:path_to_instance_specific_project s:display_name s:client_id
</pre></td></tr>
</table></div>
<p>
<p>
<p>
If a project exists at the path, the client <b>MUST</b> immediately open it.
</p>
<p>
If a project does not exist at the path, then the client <b>MUST</b> 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 <tt>save</tt> message.
</p>
<p>
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.
</p>
<p>
For clients which <b>HAVE NOT</b> specified the <tt>:switch:</tt> capability, the <tt>open</tt> message will only be delivered once, immediately following the <tt>announce</tt> response.
</p>
<p>
For clients which <b>HAVE</b> specified the <tt>:switch:</tt> capability, the client <b>MUST</b> immediately switch to the specified project or create a new one if it doesn't exist.
</p>
<p>
Clients which are incapable of switching projects or are prone to crashing upon switching <b>MUST NOT</b> include <tt>:switch:</tt> in their capability string.
</p>
<p>
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 <b>MUST PRE-PEND</b> the provided <tt>client_id</tt> 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 <tt>client_id</tt> will be a concatenation of the value of <tt>application_name</tt> sent by the client in its <tt>announce</tt> message and a unique identifier. Therefore, applications which create single JACK clients can use the value of <tt>client_id</tt> directly as their JACK client name. Applications which register multiple JACK clients (e.g. Non-Mixer) <b>MUST PRE-PEND</b> <tt>client_id</tt> value to the client names they register with JACK and the application determined part <b>MUST</b> be unique for that (JACK) client.
</p>
<p>
For example, a suitable JACK client name would be:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
$CLIENT_ID/track-1
</pre></td></tr>
</table></div>
<p>
Note that this means that the application <b>MUST NOT</b> register with JACK (or any other subsystem requiring unique names) until it receives an <tt>open</tt> message from NSM. Likewise, applications with the <tt>:switch:</tt> capability should close their JACK clients and re-create them with using the new <tt>client_id</tt>. Re-registering is necessary because the JACK API does currently support renaming existing clients, although this is a sorely needed addition.
</p>
<p>
A response is <b>REQUIRED</b> as soon as the open operation has been completed. Ongoing progress may be indicated by sending messages to <tt>/nsm/client/progress</tt>.
</p>
<h5 id="n:1.2.2.2.1.">1.2.2.2.1. Response</h5>
<p>
The client <b>MUST</b> respond to the 'open' message with:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/reply "/nsm/client/open" s:message
</pre></td></tr>
</table></div>
<p>
Or
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/error "/nsm/client/open" i:error_code s:message
</pre></td></tr>
</table></div>
<center><div class="fig table"><table id="Fig.1.4" border=1>
<caption>
<strong>Fig. 1.4.</strong> Response Codes
</caption>
<tr><th>Code</th><th>Meaning</th></tr>
<tr><td>ERR</td><td>General Error</td></tr>
<tr><td>ERR_BAD_PROJECT</td><td>An existing project file was found to be corrupt</td></tr>
<tr><td>ERR_CREATE_FAILED</td><td>A new project could not be created</td></tr>
<tr><td>ERR_UNSAVED_CHANGES</td><td>Unsaved changes would be lost</td></tr>
<tr><td>ERR_NOT_NOW</td><td>Operation cannot be completed at this time</td></tr>
</table></div></center>
<h4 id="n:1.2.2.3.">1.2.2.3. Save</h4>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/client/save
</pre></td></tr>
</table></div>
<p>
The client <b>MUST</b> immediately save the current application specific project data to the project path previously established in the 'open' message. <b>UNDER NO CIRCUMSTANCES</b> should a dialog be displayed to the user (giving a choice of where to save, etc.) This message will only be delivered after a previous <tt>open</tt> message, and may be sent any number of times within the course of a session (including zero, if the user aborts the session).
</p>
<h5 id="n:1.2.2.3.1.">1.2.2.3.1. Response</h5>
<p>
The client <b>MUST</b> respond to the 'save' message with:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/reply "/nsm/client/save" s:message
</pre></td></tr>
</table></div>
<p>
Or
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/error "/nsm/client/save" i:error_code s:message
</pre></td></tr>
</table></div>
<center><div class="fig table"><table id="Fig.1.5" border=1>
<caption>
<strong>Fig. 1.5.</strong> Response Codes
</caption>
<tr><th>Code</th><th>Meaning</th></tr>
<tr><td>ERR</td><td>General Error</td></tr>
<tr><td>ERR_SAVE_FAILED</td><td>Project could not be saved</td></tr>
<tr><td>ERR_NOT_NOW</td><td>Operation cannot be completed at this time</td></tr>
</table></div></center>
<h3 id="n:1.2.3.">1.2.3. Server to Client Informational Messages</h3>
<h4 id="n:1.2.3.1.">1.2.3.1. Session is Loaded</h4>
<p>
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.
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/client/session_is_loaded
</pre></td></tr>
</table></div>
<p>
This message does not require a response.
</p>
<h3 id="n:1.2.4.">1.2.4. Client to Server Informational Messages</h3>
<p>
These are optional messages which a client can send to the NSM server to inform it about the client's status. The client should not expect any reply to these messages. If a client intends to send a message described in this section, then it <b>MUST</b> add the appropriate value to its <tt>capabilities</tt> string when composing the <tt>announce</tt> message.
</p>
<h4 id="n:1.2.4.1.">1.2.4.1. Progress</h4>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/client/progress f:progress
</pre></td></tr>
</table></div>
<p>
For potentially time-consuming operations, such as <tt>save</tt> and <tt>open</tt>, 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.
</p>
<p>
The server will not send a response to these messages, but will relay the information to the user.
</p>
<p>
Note that even when using the <tt>progress</tt> feature, the final response to the <tt>save</tt> or <tt>open</tt> message is still <b>REQUIRED</b>.
</p>
<p>
Clients which intend to send <tt>progress</tt> messages should include <tt>:progress:</tt> in their <tt>announce</tt> capability string.
</p>
<h4 id="n:1.2.4.2.">1.2.4.2. Dirtiness</h4>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/client/is_dirty
</pre></td></tr>
</table></div>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/client/is_clean
</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.
</p>
<p>
Clients which have this capability should include <tt>:dirty:</tt> in their <tt>announce</tt> capability string.
</p>
<h4 id="n:1.2.4.3.">1.2.4.3. Status Messages</h4>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/client/message i:priority s:message
</pre></td></tr>
</table></div>
<p>
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. <tt>priority</tt> should be a number from 0 to 3, 3 being the most important.
</p>
<p>
Clients which have this capability should include <tt>:message:</tt> in their <tt>announce</tt> capability string.
</p>
<h3 id="n:1.2.5.">1.2.5. Error Code Definitions</h3>
<center><div class="fig table"><table id="Fig.1.6" border=1>
<caption>
<strong>Fig. 1.6.</strong> Error Code Definitions
</caption>
<tr><th>Symbolic Name</th><th>Integer Value</th></tr>
<tr><td>ERR_GENERAL</td><td>-1</td></tr>
<tr><td>ERR_INCOMPATIBLE_API</td><td>-2</td></tr>
<tr><td>ERR_BLACKLISTED</td><td>-3</td></tr>
<tr><td>ERR_LAUNCH_FAILED</td><td>-4</td></tr>
<tr><td>ERR_NO_SUCH_FILE</td><td>-5</td></tr>
<tr><td>ERR_NO_SESSION_OPEN</td><td>-6</td></tr>
<tr><td>ERR_UNSAVED_CHANGES</td><td>-7</td></tr>
<tr><td>ERR_NOT_NOW</td><td>-8</td></tr>
<tr><td>ERR_BAD_PROJECT</td><td>-9</td></tr>
<tr><td>ERR_CREATE_FAILED</td><td>-10</td></tr>
</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.
</p>
<h3 id="n:1.2.7.">1.2.7. Server Control API</h3>
<p>
The session manager not only manages clients via OSC, but it is itself controlled via OSC messages. The server responds to the following messages.
</p>
<p>
All of the following messages will be responded to back to the sender's address with one of the two following messages:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/reply s:path s:message
</pre></td></tr>
</table></div>
<div class="fig example"><table width=100%><tr><td><pre>
/error s:path i:error_code s:message
</pre></td></tr>
</table></div>
<p>
The first parameter of the reply is the path to the message being replied to. The <tt>/error</tt> reply includes an integer error code (non-zero indicates error). <tt>message</tt> will be a description of the error.
</p>
<p>
The possible errors are:
</p>
<center><div class="fig table"><table id="Fig.1.7" border=1>
<caption>
<strong>Fig. 1.7.</strong> Responses
</caption>
<tr><th>Code</th><th>Meaning</th></tr>
<tr><td>ERR_GENERAL</td><td>General Error</td></tr>
<tr><td>ERR_LAUNCH_FAILED</td><td>Launch failed</td></tr>
<tr><td>ERR_NO_SUCH_FILE</td><td>No such file</td></tr>
<tr><td>ERR_NO_SESSION</td><td>No session is open</td></tr>
<tr><td>ERR_UNSAVED_CHANGES</td><td>Unsaved changes would be lost</td></tr>
</table></div></center>
<dl>
<dt><em>/nsm/server/add s:path_to_executable</em></dt>
<p>
Adds a client to the current session.
</p>
</dl><dl>
<dt><em>/nsm/server/save</em></dt>
<p>
Saves the current session.
</p>
</dl><dl>
<dt><em>/nsm/server/load s:project_name</em></dt>
<p>
Saves the current session and loads a new session.
</p>
</dl><dl>
<dt><em>/nsm/server/new s:project_name</em></dt>
<p>
Saves the current session and creates a new session.
</p>
</dl><dl>
<dt><em>/nsm/server/close</em></dt>
<p>
Saves and closes the current session.
</p>
</dl><dl>
<dt><em>/nsm/server/abort</em></dt>
<p>
Closes the current session <b>WITHOUT SAVING</b>
</p>
</dl><dl>
<dt><em>/nsm/server/quit</em></dt>
<p>
Saves and closes the current session and terminates the server.
</p>
</dl><dl>
<dt><em>/nsm/server/duplicate s:new_project </em></dt>
<p>
<dl>
<dt><em>/nsm/server/list </em></dt>
<p>
Lists available projects. One <tt>/reply</tt> message will be sent for each existing project.
</p>
</dl><h4 id="n:1.2.7.1.">1.2.7.1. Client to Client Communication</h4>
<p>
If the server includes <tt>:broadcast:</tt> 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 <tt>/nsm/server/broadcast</tt>.
</p>
<p>
The format of this message is as follows:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/server/broadcast s:path [arguments...]
</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).
</p>
<p>
For example the message:
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/nsm/server/broadcast /tempomap/update "0,120,4/4:12351234,240,4/4"
</pre></td></tr>
</table></div>
<p>
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.
</p>
<div class="fig example"><table width=100%><tr><td><pre>
/tempomap/update "0,120,4/4:12351234,240,4/4"
</pre></td></tr>
</table></div>
<p>
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.
</p>
</div>
</body>
</html>

33
session/doc/NSM.mu → session/doc/API.mu
View File

@ -2,10 +2,11 @@
! title Non Session Management API
! author Jonathan Moore Liles #(email,male@tuxfamily.org)
! date August 1, 2010
! revision Version 0.8
-- Table Of Contents
: Non Session Management API version 0.8
: 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
@ -109,6 +110,11 @@
`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
@ -118,7 +124,7 @@
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 i:api_version_major i:api_version_minor i:pid
> /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.
@ -136,7 +142,7 @@
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
for up to one second while awaiting the `announce` reply and
breifly while awaiting the `announce` reply and
subsequent `open` message.
`capabilities` *MUST* be a string containing a colon separated list
@ -171,6 +177,7 @@
// Available Server Capabilities
[[ Name, Description
[[ server_control, client-to-server control
[[ broadcast, server responds to /nsm/server/broadcast message
A client should not consider itself to be under session management
until it receives this response. For example, the Non applications
@ -285,7 +292,7 @@
because the JACK API does currently support renaming existing
clients, although this is a sorely needed addition.
A response is *REQUIRED* *AFTER* the open operation has been
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`.
@ -490,14 +497,14 @@
server.
Clients may send messages to the server at the path
`\/broadcast`.
`\/nsm\/server\/broadcast`.
The format of this message is as follows:
> /nsm/server/broadcast [any parameters...]
> /nsm/server/broadcast s:path [arguments...]
The message will then be relayed to all clients in the session at
the path `\/nsm\/client\/broadcast`.
the path `path` (with the arguments shifted by one).
For example the message:
@ -505,12 +512,10 @@
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. Here the string
`\/tempomap\/update` is not an OSC path but merely a name-space
qualifier by which the receivers can filter messages.
by updating their own tempo maps.
> /nsm/client/broadcast /tempomap/update "0,120,4/4:12351234,240,4/4"
> /tempomap/update "0,120,4/4:12351234,240,4/4"
Clients might use this feature to establish peer to peer OSC
communication with symbolic names without having to remember the OSC
ports of peers across sessions.
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.

242
session/doc/MANUAL.mu Normal file
View File

@ -0,0 +1,242 @@
! title The Non Session Manager User Manual
! author Jonathan Moore Liles #(email,male@tuxfamily.org)
! date February 25, 2012
-- Table Of Contents
: User Manual
:: The Non Session Manager Graphical Interface
/ Non Session Manager
< nsm.png
The Non Session Manager is a graphical interface to the NSM Daemon
(nsmd). By default, running the command `non-session-manager` will
start both the GUI and an instance of the daemon.
If a different session root than the default is desired, it may be
specified on the command-line as follows:
> non-session-manager -- --session-root path
This command will instruct the instance of nsmd that the GUI starts
to use `path` as the session root.
All session data is stored in per-session sub-directories of the
/Session Root/.
::: Session Operations
:::: Open
There are two ways to open a session.
The first is to click the Open button and type in the exact name of
an existing session. The second is to click on the desired session
name in the session list panel in the left hand half of the
interface.
Either way, opening a session saves the current session and switches
to the new one. Clients which are capable of switching projects
without restarting are instructed to do so, resulting in very fast
session open times when such clients are participating in both
sessions.
Clients cannot be added until a session is open, either by /Open/ or
/New/.
As each client launches, a status bar representing it will be added
to the client list in the hand panel of the interface. For clients
which are capable of reporting their progress, a progress bar will
also become active.
Only clients supporting the NSM protocol can be told what to open
and when to save. Clients not supporting NSM may still be added to
the session, but their behavior is undefined other than that NSM can
invoke and kill them.
:::: Close
This option saves and closes the current session. All clients
participating in the session are told to quit. Note that, as
mentioned in the preceding section, in NSM it is not necessary to
close one session before opening another.
:::: Abort
This option closes the current session *without saving*.
:::: Save
This option saves the current session, instructing clients
supporting the NSM protocol to save.
:::: New
This option saves the current session (if one is open) and creates a
new one. The user is prompted for a session name. Session names are
paths under the defined /Session Root/. A session name may include
any number of hierarchical elements, which need not be pre-existing.
For example, one might name a session as follows:
> Albums/Magnum Opus/The Best Song Ever Produced
When inspecting /Session Root/ in a file manager, the above
represents exactly the path you would see.
Renaming a session is not currently supported, but one may simply
move directories around under /Session Root/ and NSM will detect the
new layout upon the next invocation. The session name is not stored
anywhere except in its path.
Advanced users may choose to use symbolic links to organize their
sessions. For example, one could store all their songs under
'Songs\/' and create an 'Albums/\' directory structure which uses
symlinks to point at the songs stored.
:::: Duplicate
Templates are supported in by the Non Session Manager via
duplication. Clicking on the /Duplicate/ button with a session open
will prompt the user for a new session name. The daemon will then
perform a recursive file copy of the session and open the copy.
Obviously, this should be avoided for sessions containing audio
data, as the copy would be very time consuming.
To create a template in the first place, simply use /New/ to start a
new session (preferably with a name beginning with Template\/), add
the desired clients to it, and configure them (e.g. add plugins,
make JACK connections, etc.)
Now, any time you want to start a session from that template, simply
switch to the template session and click /Duplicate/ to create a new
session based on it.
:::: Add Client
This option will prompt the user for the executable name of the
client to be added to the session. It is not necessary to type the
full path (the PATH environment variable will be searched to find
the executable).
::: Removing a Client From a Session
If a client dies unexpectedly or is closed by the user (e.g. by
closing its main window), Non Session Manager will detect this and
two buttons will appear on that Client's status bar. One button, the
arrow, causes the client to be restarted, and to reopen its project
file where it left off. The /X/ button causes the client to be
permanently removed from the session.
:: The NSM Daemon
The NSM Daemon (nsmd) is launched automatically by the Non Session
Manager interface whenever one is not found to be already running at
the URL specified in the environment
Users who are not attempting setup advanced modes like shared
sessions between machines will not normally need to even know that
`nsmd` is running.
But for those advanced users, here are the command-line options for launching
nsmd separately from the GUI.
> nsmd [--session-root path] [--osc-port port] [--detach]
The `--session-root` option allows one to override default /Session
Root/ is "$HOME\/NSM Sessions" (this option can also be passed to the
GUI, which will hand it over to the daemon).
`--osc-port` instructs the daemon to bind to a specific UDP port
number instead of selecting an available port automatically.
`--detach` instructs the daemon to close its standard input and
output and go completely into the background. This is useful for
starting the daemon remotely with `rsh`.
When nsmd starts, it will print a string of the following form its
standard output.
> NSM_URL=osc.udp://foo.bar.net:17551/
This is the OSC URL for the daemon process. If this URL is included
in the environment (by either using a fixed port number or starting
nsmd early in the initialization process [like in your .xinitrc]
extracting the URL from its output.) then any NSM capable client
will join the current session when started, even if started from
outside the Non Session Manager interface (e.g. by your desktop
environment's program launch menu).
::: Multiple NSMD Instance
When dealing with multiple instances of nsmd, whether they be on the
same machine or different machines, it is most convenient to use
fixed port numbers.
:::: Distributed Session Management
In some situations it is necessary to have different audio programs
running on different machines connected by S\/PDIF\/or analog wiring
or over TCP\/IP as achieved by `netjack`. Usually the reason for
doing this is that neither machine is powerful enough to do all the
DSP or synthesis by itself.
Needless to say, these configurations have historically been
extremely difficult to manage--requiring heavy scripting or lots of
manual setup.
NSM is the first and currently only system capable of managing these
sessions.
Let us assume the following conditions for our example:
+ We want to distribute a session across two hosts, Host-A and Host-B, on the local area network
+ Each host has a completely independent file system (i.e. not NFS)
+ We have appropriate access to both hosts.
The first step is to decide what port numbers to use. Let's choose
`6661` for Host-A and `6662` for Host-B.
If either host is running a firewall, then these ports must be opened explicitly!
To start the daemon on host A:
> user@host-a:~$ nsmd --detach --session-root "$HOME/distributed-nsm-sessions" --osc-port 6661
To start the daemon on host B (conveniently from host A, via rsh)
> user@host-a:~$ rsh host-b nsmd --detach --session-root "\$HOME/distributed-nsm-sessions" --osc-port 6662
Note that in the above example, there is a backslash in "$HOME",
this is because otherwise the variable would be expanded on the
local machine, giving the local value rather than what we intended.
Now that both daemons are running, we can start the Non Session
Manager interface with the following command:
> user@host-a:~$ non-session-manager --nsm-url osc.udp://host-a:6661 --nsm-url osc.udp://host-b:6662
The Non Session Manager interface will then connect to the daemons
on both hosts. Creating a new session will create separate session
files on each host. When adding a client, the interface will present
the user with a choice of which host to invoke the client on. Aside
from that it is just like managing any other session. Sessions can
be opened, saved, switched between, etc. and the desired effect will
be seen on each host.
:::: Multiple Sessions On One Host
Simply starting two (or more) instances of the Non Session Manager
interface on the same machine (when the NSM\_URL environment
variable is unset) will result in the ability to have two different
sessions open at the same time on the same host. The instances are
prohibited from opening two instances of the same session.
Imagining a useful application of this feature is left as an
exercise for the user.

25
session/doc/Makefile Normal file
View File

@ -0,0 +1,25 @@
SRCS=$(wildcard *.mu)
OBJS=$(SRCS:.mu=.html)
%.html: %.mu
@ echo Mupping $<...
@ mup.wrapper html $<
.PHONY: all clean
all: $(OBJS)
upload: all
@ ln -sf OVERVIEW.html index.html
@ rsync -L mup.css MANUAL.html index.html *.png ssh.tuxfamily.org:/home/non/non-mixer.tuxfamily.org-web/htdocs
@ rm -f index.html
install:
@ mkdir -p $(DOCUMENT_PATH)/non-session-manager
@ cp $(OBJS) *.png mup.css ../../COPYING $(DOCUMENT_PATH)/non-session-manager
# @ ln -sf $(PIXMAP_PATH)/logo.png $(DOCUMENT_PATH)
clean:
rm -f $(OBJS)

BIN
session/doc/logo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 23 KiB

278
session/doc/logo.svg Normal file
View File

@ -0,0 +1,278 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:osb="http://www.openswatchbook.org/uri/2009/osb"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="295.35672"
height="172.49957"
id="svg2"
version="1.1"
inkscape:version="0.48.1 r9760"
sodipodi:docname="logo.svg"
inkscape:export-filename="/home/male/prog/non-daw/session/doc/logo.png"
inkscape:export-xdpi="77.739128"
inkscape:export-ydpi="77.739128">
<defs
id="defs4">
<linearGradient
id="linearGradient5209"
osb:paint="solid">
<stop
style="stop-color:#ffffff;stop-opacity:1;"
offset="0"
id="stop5211" />
</linearGradient>
<filter
inkscape:collect="always"
id="filter5252"
x="-0.051939286"
width="1.1038786"
y="-0.80208468"
height="2.6041694"
color-interpolation-filters="sRGB">
<feGaussianBlur
inkscape:collect="always"
stdDeviation="5.3552102"
id="feGaussianBlur5254" />
</filter>
<filter
inkscape:collect="always"
id="filter5310"
x="-0.50822306"
width="2.0164461"
y="-0.88939029"
height="2.7787807"
color-interpolation-filters="sRGB">
<feGaussianBlur
inkscape:collect="always"
stdDeviation="1.058798"
id="feGaussianBlur5312" />
</filter>
<filter
color-interpolation-filters="sRGB"
inkscape:collect="always"
id="filter5310-2"
x="-0.50822306"
width="2.0164461"
y="-0.88939029"
height="2.7787807">
<feGaussianBlur
inkscape:collect="always"
stdDeviation="1.058798"
id="feGaussianBlur5312-9" />
</filter>
<filter
color-interpolation-filters="sRGB"
inkscape:collect="always"
id="filter5310-9"
x="-0.50822306"
width="2.0164461"
y="-0.88939029"
height="2.7787807">
<feGaussianBlur
inkscape:collect="always"
stdDeviation="1.058798"
id="feGaussianBlur5312-4" />
</filter>
<filter
inkscape:collect="always"
id="filter3832"
color-interpolation-filters="sRGB">
<feGaussianBlur
inkscape:collect="always"
stdDeviation="2.4577776"
id="feGaussianBlur3834" />
</filter>
<filter
inkscape:collect="always"
id="filter5252-1"
x="-0.051939286"
width="1.1038786"
y="-0.80208468"
height="2.6041694"
color-interpolation-filters="sRGB">
<feGaussianBlur
inkscape:collect="always"
stdDeviation="5.3552102"
id="feGaussianBlur5254-7" />
</filter>
</defs>
<sodipodi:namedview
id="base"
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1.0"
inkscape:pageopacity="0.0"
inkscape:pageshadow="2"
inkscape:zoom="1.979899"
inkscape:cx="96.05814"
inkscape:cy="61.769085"
inkscape:document-units="px"
inkscape:current-layer="layer1"
showgrid="false"
fit-margin-top="0"
fit-margin-left="0"
fit-margin-right="0"
fit-margin-bottom="0"
inkscape:window-width="1920"
inkscape:window-height="1032"
inkscape:window-x="-2"
inkscape:window-y="25"
inkscape:window-maximized="1" />
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1"
transform="translate(-146.60735,-178.96954)">
<rect
style="opacity:0.98999999;fill:#323f00;fill-opacity:1;stroke:#000000;stroke-width:1.07099998;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
id="rect2985"
width="294.28571"
height="171.42857"
x="147.14285"
y="179.50504"
ry="48.57143"
rx="14.226269" />
<rect
style="opacity:0.98999999;fill:#ffffff;fill-opacity:0.44769874;stroke:#000000;stroke-width:0.76099998;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:0.73127753;stroke-dasharray:3.044, 3.044;stroke-dashoffset:0;filter:url(#filter5252)"
id="rect5223"
width="247.45247"
height="16.023874"
x="169.8452"
y="186.4931"
rx="12.709717"
ry="19.186098"
transform="matrix(0.88439366,0,0,0.22337601,38.724736,142.33502)" />
<text
xml:space="preserve"
style="font-size:56px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:center;line-height:100%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:0.84583315;stroke:none;filter:url(#filter3832);font-family:Westminster;-inkscape-font-specification:Westminster Medium"
x="288.92859"
y="227.00504"
id="text2989"
sodipodi:linespacing="100%"><tspan
sodipodi:role="line"
id="tspan2991"
x="288.92859"
y="227.00504">NON</tspan><tspan
sodipodi:role="line"
x="288.92859"
y="283.00504"
id="tspan2995"> SESSION</tspan><tspan
sodipodi:role="line"
x="288.92859"
y="339.00504"
id="tspan2993"> MANAGER</tspan></text>
<g
id="g5369"
transform="matrix(1.4821254,0,0,1.4821254,-74.164744,-103.33609)">
<path
transform="translate(83.571429,35)"
d="m 87.142859,190.57646 c 0,4.53663 -3.677661,8.21429 -8.214285,8.21429 -4.536625,0 -8.214286,-3.67766 -8.214286,-8.21429 0,-4.53662 3.677661,-8.21428 8.214286,-8.21428 4.536624,0 8.214285,3.67766 8.214285,8.21428 z"
sodipodi:ry="8.2142859"
sodipodi:rx="8.2142859"
sodipodi:cy="190.57646"
sodipodi:cx="78.928574"
id="path5258"
style="opacity:0.98999999;fill:#ccc000;fill-opacity:0.77083333;stroke:#0b0700;stroke-width:0.76099998;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
sodipodi:type="arc" />
<path
transform="matrix(1.177115,0,0,1.4048538,39.397772,-76.945131)"
d="m 105.71429,213.43361 c 0,0.78898 -1.11929,1.42857 -2.5,1.42857 -1.38072,0 -2.5,-0.63959 -2.5,-1.42857 0,-0.78898 1.11928,-1.42857 2.5,-1.42857 1.38071,0 2.5,0.63959 2.5,1.42857 z"
sodipodi:ry="1.4285715"
sodipodi:rx="2.5"
sodipodi:cy="213.43361"
sodipodi:cx="103.21429"
id="path5296"
style="opacity:0.98999999;fill:#ffffff;fill-opacity:0.87083333;stroke:none;filter:url(#filter5310)"
sodipodi:type="arc" />
<path
transform="translate(83.214284,56.78572)"
d="m 87.142859,190.57646 c 0,4.53663 -3.677661,8.21429 -8.214285,8.21429 -4.536625,0 -8.214286,-3.67766 -8.214286,-8.21429 0,-4.53662 3.677661,-8.21428 8.214286,-8.21428 4.536624,0 8.214285,3.67766 8.214285,8.21428 z"
sodipodi:ry="8.2142859"
sodipodi:rx="8.2142859"
sodipodi:cy="190.57646"
sodipodi:cx="78.928574"
id="path5258-4"
style="opacity:0.98999999;fill:#00a115;fill-opacity:0.77083333;stroke:#0b0700;stroke-width:0.76099998;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
sodipodi:type="arc" />
<path
transform="matrix(1.177115,0,0,1.4048538,39.040627,-55.159411)"
d="m 105.71429,213.43361 c 0,0.78898 -1.11929,1.42857 -2.5,1.42857 -1.38072,0 -2.5,-0.63959 -2.5,-1.42857 0,-0.78898 1.11928,-1.42857 2.5,-1.42857 1.38071,0 2.5,0.63959 2.5,1.42857 z"
sodipodi:ry="1.4285715"
sodipodi:rx="2.5"
sodipodi:cy="213.43361"
sodipodi:cx="103.21429"
id="path5296-3"
style="opacity:0.98999999;fill:#ffffff;fill-opacity:0.87083333;stroke:none;filter:url(#filter5310-2)"
sodipodi:type="arc" />
<path
transform="translate(82.499998,78.571434)"
d="m 87.142859,190.57646 c 0,4.53663 -3.677661,8.21429 -8.214285,8.21429 -4.536625,0 -8.214286,-3.67766 -8.214286,-8.21429 0,-4.53662 3.677661,-8.21428 8.214286,-8.21428 4.536624,0 8.214285,3.67766 8.214285,8.21428 z"
sodipodi:ry="8.2142859"
sodipodi:rx="8.2142859"
sodipodi:cy="190.57646"
sodipodi:cx="78.928574"
id="path5258-5"
style="opacity:0.98999999;fill:#b20000;fill-opacity:0.77083333;stroke:#0b0700;stroke-width:0.76099998;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
sodipodi:type="arc" />
<path
transform="matrix(1.177115,0,0,1.4048538,38.326341,-33.373697)"
d="m 105.71429,213.43361 c 0,0.78898 -1.11929,1.42857 -2.5,1.42857 -1.38072,0 -2.5,-0.63959 -2.5,-1.42857 0,-0.78898 1.11928,-1.42857 2.5,-1.42857 1.38071,0 2.5,0.63959 2.5,1.42857 z"
sodipodi:ry="1.4285715"
sodipodi:rx="2.5"
sodipodi:cy="213.43361"
sodipodi:cx="103.21429"
id="path5296-5"
style="opacity:0.98999999;fill:#ffffff;fill-opacity:0.87083333;stroke:none;filter:url(#filter5310-9)"
sodipodi:type="arc" />
</g>
<text
xml:space="preserve"
style="font-size:56px;font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;text-align:center;line-height:100%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#b3b3b3;fill-opacity:0.84583285;stroke:none;font-family:Westminster;-inkscape-font-specification:Westminster Medium"
x="291.35391"
y="226.2814"
id="text2989-8"
sodipodi:linespacing="100%"><tspan
sodipodi:role="line"
id="tspan2991-6"
x="291.35391"
y="226.2814">NON</tspan><tspan
sodipodi:role="line"
x="291.35391"
y="282.2814"
id="tspan2995-8"> SESSION</tspan><tspan
sodipodi:role="line"
x="291.35391"
y="338.2814"
id="tspan2993-8"> MANAGER</tspan></text>
<rect
style="opacity:0.98999999;fill:#ffffff;fill-opacity:0.44769874;stroke:#000000;stroke-width:0.76099998;stroke-linecap:square;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-opacity:0.73127753;stroke-dasharray:3.044, 3.044;stroke-dashoffset:0;filter:url(#filter5252-1)"
id="rect5223-2"
width="247.45247"
height="16.023874"
x="169.8452"
y="186.4931"
rx="12.709717"
ry="19.186098"
transform="matrix(0.88439366,0,0,0.22337601,35.188918,302.30707)" />
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

2
session/src/nsmd.C
View File

@ -752,7 +752,7 @@ OSC_HANDLER( announce )
"Howdy, what took you so long?" :
"Well hello, stranger. Welcome to the party.",
APP_TITLE,
":server-control:" );
":server-control:broadcast:" );
if ( gui_is_active )
{

53
timeline/doc/MANUAL.html
View File

@ -73,7 +73,15 @@ June 20, 2008<br>
<li><a href="#n:1.1.11.">1.1.11. Automation</a>
</ul></ul></ul></ul><hr></div>
<ul><li><a href="#n:1.1.11.1.">1.1.11.1. Output Mode</a>
<ul><li><a href="#n:1.1.11.1.1.">1.1.11.1.1. Control Voltage</a>
<li><a href="#n:1.1.11.1.2.">1.1.11.1.2. Control Signal</a>
</ul><li><a href="#n:1.1.11.2.">1.1.11.2. Interpolation Mode</a>
</ul></ul></ul></ul></ul><hr></div>
<h1 id="n:1.">1. User Manual</h1>
<h2 id="n:1.1.">1.1. The Timeline Editor</h2>
<center><div class="fig image"><table id="Fig.1.1" border=1>
@ -312,11 +320,52 @@ Add an annotation sequence to a track by right-clicking on the track header to b
<tr><td><img src="automation.png" alt="fig. 1.13"></td></tr>
</table></div></center>
<p>
Each track may have any number of control sequences attached to it. A control sequence comprises a series of points in time (X axis) and intensity (Y axis). Add a control sequence to a track by picking <i>Add control</i> from its context menu. A control sequence may be named by right clicking on it to bring up the context menu, then picking 'Rename'. The output of a control sequence is similar control voltages generated by analog equipment. A control sequence can be used to control anything that can accept CV style input. Useful targets include the Non Mixer, and SpiralSynthModular.
Each track may have any number of control sequences attached to it. A control sequence comprises a series of points in time (X axis) and intensity (Y axis). Add a control sequence to a track by picking <i>Add control</i> from its context menu. A control sequence may be named by right clicking on it to bring up the context menu, then picking <i>Rename</i>. The output of a control sequence can be set to one of two modes <i>Control Voltage (JACK)</i> or <i>Control Signal (OSC)</i>.
</p>
<div class=admonition>
<table width=100%>
<tr><td>NOTE:
Since release 1.1.0, Control Signal is now the default output mode for Control Sequences.
If you have existing projects and wish to continue using Control Voltage output,
you must set the mode to Control Voltage manually.
</td></table>
</div>
<p>
Click anywhere on the control sequence to add a new control point. Control points can be dragged around and selected just like other objects on the timeline. They can even be part of the same selection as regions, permitting you to move regions and control points together in lock-step.
</p>
<h4 id="n:1.1.11.1.">1.1.11.1. Output Mode</h4>
<h5 id="n:1.1.11.1.1.">1.1.11.1.1. Control Voltage</h5>
<p>
<i>Control Voltage</i> is similar to control voltages generated by analog equipment. Setting the Control Sequence mode to Control Voltage will create a JACK output port whose contents simulate an analogue Control Voltage signal. This mode can be used to control anything that accepts CV style input. Useful targets include the Non-Mixer, and SpiralSynthModular.
</p>
<h5 id="n:1.1.11.1.2.">1.1.11.1.2. Control Signal</h5>
<p>
The <i>Control Signal</i> mode uses a signal routing layer on top of the OSC protocol to intelligently and automatically discover and control any module parameter in Non-Mixer. The output of one Control Sequence may be connected to any number of Control Signal inputs available in Non-Mixer.
</p>
<p>
Control Signals are more efficient than Control Voltages when a large number of parameters are being automated.
</p>
<center><div class="fig image"><table id="Fig.1.14" border=1>
<caption>
<strong>Fig. 1.14.</strong> Control Signal Connection
</caption>
<tr><td><img src="control-signals.png" alt="fig. 1.14"></td></tr>
</table></div></center>
<h4 id="n:1.1.11.2.">1.1.11.2. Interpolation Mode</h4>
<center><div class="fig image"><table id="Fig.1.15" border=1>
<caption>
<strong>Fig. 1.15.</strong> Effect of Interpolation Mode
</caption>
<tr><td><img src="control-points.png" alt="fig. 1.15"></td></tr>
</table></div></center>
<p>
The interpolation mode controls how the relatively small number of Control Points is transformed into a continuously varying signal. The options are <i>None</i> and <i>Linear</i>.
</p>
<p>
When its Interpolation mode is set to <i>None</i>, a Control Sequence will output discrete jumps in value upon the playhead passing each Control Point. This can be useful when instantaneous changes in value are required, such as sudden muting, or changing the modes of plugins.
</p>
</div>
</body>
</html>

63
timeline/doc/MANUAL.mu
View File

@ -267,20 +267,61 @@
/ Control Sequence
< automation.png
Each track may have any number of control sequences attached to it. A control
sequence comprises a series of points in time (X axis) and intensity (Y
axis). Add a control sequence to a track by picking /Add control/ from its
context menu. A control sequence may be named by right clicking on it to
bring up the context menu, then picking 'Rename'. The output of a control
sequence is similar control voltages generated by analog equipment. A control
sequence can be used to control anything that can accept CV style input.
Useful targets include the Non Mixer, and SpiralSynthModular.
Each track may have any number of control sequences attached to
it. A control sequence comprises a series of points in time (X axis)
and intensity (Y axis). Add a control sequence to a track by picking
/Add control/ from its context menu. A control sequence may be named
by right clicking on it to bring up the context menu, then picking
/Rename/. The output of a control sequence can be set to one of two
modes /Control Voltage \(JACK\)/ or /Control Signal \(OSC\)/.
{ NOTE:
{ Since release 1.1.0, Control Signal is now the default output mode for Control Sequences.
{ If you have existing projects and wish to continue using Control Voltage output,
{ you must set the mode to Control Voltage manually.
Click anywhere on the control sequence to add a new control point. Control
points can be dragged around and selected just like other objects on the
timeline. They can even be part of the same selection as regions, permitting
you to move regions and control points together in lock-step.
# :: The Mixer
# ::: Tracks
# ::: Panning
:::: Output Mode
::::: Control Voltage
/Control Voltage/ is similar to control voltages generated by analog
equipment. Setting the Control Sequence mode to Control Voltage will
create a JACK output port whose contents simulate an analogue
Control Voltage signal. This mode can be used to control anything
that accepts CV style input. Useful targets include the Non-Mixer,
and SpiralSynthModular.
::::: Control Signal
The /Control Signal/ mode uses a signal routing layer on top of the
OSC protocol to intelligently and automatically discover and control
any module parameter in Non-Mixer. The output of one Control
Sequence may be connected to any number of Control Signal inputs
available in Non-Mixer.
Control Signals are more efficient than Control Voltages when a
large number of parameters are being automated.
/ Control Signal Connection
< control-signals.png
:::: Interpolation Mode
/ Effect of Interpolation Mode
< control-points.png
The interpolation mode controls how the relatively small number of
Control Points is transformed into a continuously varying
signal. The options are /None/ and /Linear/.
When its Interpolation mode is set to /None/, a Control Sequence
will output discrete jumps in value upon the playhead passing each
Control Point. This can be useful when instantaneous changes in
value are required, such as sudden muting, or changing the modes of
plugins.

5
timeline/doc/OVERVIEW.html
View File

@ -59,12 +59,15 @@ March 1, 2008<br>
</ul></ul><hr></div>
<h1 id="n:1.">1. Overview</h1>
<center><div class="fig image"><table border=1>
<tr><td><img src="tle.png" alt="fig. "></td></tr>
</table></div></center>
<h2 id="n:1.1.">1.1. Description</h2>
<p>
The Non DAW is a powerful, reliable and fast modular Digital Audio Workstation system, released under the GNU General Public License (GPL). It utilizes the JACK Audio Connection Kit for inter-application audio I/O and the FLTK GUI toolkit for a fast and lightweight user interface.
</p>
<p>
Please see the <a class=ext href="MANUAL.html">Manual</a> for more information.
Please see the <a class=ext href="MANUAL.html">Manual</a> for more information (and lots of screenshots).
</p>
<h2 id="n:1.2.">1.2. What it is not</h2>
<p>

7
timeline/doc/OVERVIEW.mu
View File

@ -8,6 +8,8 @@
: Overview
< tle.png
:: Description
The Non DAW is a powerful, reliable and fast modular Digital Audio
@ -16,7 +18,8 @@
inter-application audio I\/O and the FLTK GUI toolkit for a fast and
lightweight user interface.
Please see the #(url,MANUAL.html,Manual) for more information.
Please see the #(url,MANUAL.html,Manual) for more information (and
lots of screenshots).
:: What it is not
@ -257,6 +260,8 @@
* FLTK >= 1.1.7 (with `fluid`)
* JACK >= 0.103.0
* libsndfile >= 0.18.0
* liblo >= 0.26
* libsigc++ >= 2.0.0
; Community

BIN
timeline/doc/crappy-screenshot.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 104 KiB