diff --git a/mixer/doc/MANUAL.html b/mixer/doc/MANUAL.html index 88daea2..624ef9f 100644 --- a/mixer/doc/MANUAL.html +++ b/mixer/doc/MANUAL.html @@ -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:
-/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 port will be bound automatically (the exact OSC URL will always be 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. +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.
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 |
@@ -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'.
-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.
@@ -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 +
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. + |
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:
diff --git a/mixer/doc/MANUAL.mu b/mixer/doc/MANUAL.mu
index b6a4901..bee26a7 100644
--- a/mixer/doc/MANUAL.mu
+++ b/mixer/doc/MANUAL.mu
@@ -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
diff --git a/mixer/doc/OVERVIEW.html b/mixer/doc/OVERVIEW.html
index 11a4828..1799f37 100644
--- a/mixer/doc/OVERVIEW.html
+++ b/mixer/doc/OVERVIEW.html
@@ -51,12 +51,15 @@ February 1, 2010
![]() |
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.
-Please see the Manual for more information. +Please see the Manual for more information (and lots of screenshots).
@@ -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.
-Control data is expressed as Control Voltage (CV). +Control data is expressed either as Control Voltage (CV) or Control Signals.
@@ -115,7 +118,7 @@ There is no limit imposed by Non Mixer on the total number of strips or Mixer in
-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. +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.
@@ -155,6 +158,8 @@ The following libraries are required to build Non DAW and Non Mixer
Feel free to drop by the #non channel on irc.freenode.net. diff --git a/mixer/doc/OVERVIEW.mu b/mixer/doc/OVERVIEW.mu index 771dd50..15857f6 100644 --- a/mixer/doc/OVERVIEW.mu +++ b/mixer/doc/OVERVIEW.mu @@ -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 diff --git a/session/doc/API.html b/session/doc/API.html new file mode 100644 index 0000000..1ed3a9d --- /dev/null +++ b/session/doc/API.html @@ -0,0 +1,542 @@ + +
+ + + ++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. +
++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. +
++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. +
++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. +
++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. +
++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. +
++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. +
++ This option MUST be disabled unless its meaning is to disconnect the application from session management. +
++This option may behave as normal (even possibly asking the user to confirm exiting). +
++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. +
++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 by 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:" +
+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 |
+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: +
+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 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: +
+Code | Meaning |
---|---|
ERR_GENERAL | General Error |
ERR_INCOMPATIBLE_API | Incompatible API version |
ERR_BLACKLISTED | Client has been blacklisted. |
+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": +
++/reply s:path s:message + |
+/error s:path i:error_code s:message + |
+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. +
++/nsm/client/open s:path_to_instance_specific_project s:display_name s:client_id + |
+
+
+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. +
++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 + |
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 |
+/nsm/client/save + |
+The client MUST immediately save the current application specific project data to the project path previously established in the 'open' message. UNDER NO CIRCUMSTANCES 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 open message, and may be sent any number of times within the course of a session (including zero, if the user aborts the session). +
++The client MUST respond to the 'save' message with: +
++/reply "/nsm/client/save" s:message + |
+Or +
++/error "/nsm/client/save" i:error_code s:message + |
Code | Meaning |
---|---|
ERR | General Error |
ERR_SAVE_FAILED | Project could not be saved |
ERR_NOT_NOW | Operation cannot be completed at this time |
+ 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. +
++/nsm/client/session_is_loaded + |
+This message does not require a response. +
++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 MUST add the appropriate value to its capabilities string when composing the announce message. +
++/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. +
++/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. +
++/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. +
+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 |
+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. +
++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 back to 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: +
+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 |
+Adds a client to the current session. +
++Saves the current session. +
++Saves the current session and loads a new session. +
++Saves the current session and creates a new session. +
++Saves and closes the current session. +
++Closes the current session WITHOUT SAVING +
++Saves and closes the current session and terminates the server. +
++
+Lists available projects. One /reply message will be sent for each existing project. +
++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. +
+![]() |
-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.
++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. +
++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. +
+![]() |
![]() |
+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. +