Most of my music and sound work requires only a few applications. If I'm
recording a song, I use a digital audio workstation (DAW) with a few plugins
launched from within the
sequencer, and if I make something in Csound, it's usually done completely
in the AVSynthesis environment. The DAW and AVSynthesis programs are
self-contained; they need no external software to store and recall their
internal and external connections, plugin states, MIDI controller
settings, and so forth. When I work in those environments, I know that I can
open a previously saved session and have all former connections, states,
and settings restored to their last conditions.
Recently I've been experimenting with a more heterogeneous workspace with
several applications connected in a modular system. The JACK server allows
flexible inter-application data exchange, and some powerful setups can
be configured with the many JACK-compliant sequencers, synthesizers, and
plugins. Unfortunately, the reconnection and reconfiguration of a complex
modular system becomes a real problem when you've opened a DAW — with
plugins, of course — and half a dozen standalone synthesizers are active with an
equal number of standalone audio processors, each with its own internal settings
and configuration details. The resulting maze of connections and configurations
takes time to re-establish, valuable time that could be better spent on
making music. Fortunately, help is here, thanks to Linux audio session
A session manager (or "session handler") is a utility that stores and
recalls every aspect of your
audio production session. Typically each session has a unique identifier,
so a click or two can reload, reconfigure, and reconnect all the pieces of
your session exactly as you saved it. For smaller sessions, a manager may be
a neat convenience, but for large-scale sessions with dozens of components
the session manager is indispensable.
Session managers work in a few different ways, though all do the same
things. Some can only manage applications that are JACK-compliant or that
subscribe to a particular session protocol; others are more
accommodating. Most managers include a graphical interface, but, since this is Linux, there
are non-graphical solutions too. In fact, even the bash shell
makes it easy to write a script that
will relaunch an entire session. Such scripts are powerful and effective,
but interaction is limited and it may be difficult to monitor and store
state changes. Changes to your basic setup configuration may require
additions to the script outside the session.
Session management protocols are designed to handle these matters. A basic
session handler should be able to restore a session exactly as the user
left it, but the handler must deal with a mash-up of harsh realities, including
the internal and external states of host and clients (with display
positions and sizes), the instantiation of all active plugins with their
selected presets and internal edits, the loading of all necessary files
used by the project, and the connections between the components in the system,
including audio and MIDI I/O, track and bus assignments, and any other
routing considerations. The session manager must be toolkit- and
distribution-independent and it must handle the full variety of plugin and
formats. It should also be indifferent to the audio backend, but it should
be aware of system services such as D-Bus. Finally, the manager should
provide robust error reporting when things go wrong.
Session managers typically provide a library of services and a daemon to
monitor and report process changes. An application that is linked to the
manager's library can be monitored by the session daemon and update its
state data for saving and recall. Obviously, the efficiency of any
session management software depends on the services provided by the library
and the client's implementation of the library services (if any).
In this article we'll look at the current crop of session managers for
Linux audio production. We begin with a little history to understand how
we've come to the present state of the art.
From LADCCA to LASH
The first attempt at Linux audio session management appeared as LADCCA, the
Linux Audio Developer's Configuration and Connection API. Developer Bob
Reference Manual indicates that, even at the earliest stage, developers
were aware of the basic problems and issues. LADCCA's development group
expanded and the project eventually became LASH, the Linux Audio Session
Handler. Focus remained on managing applications written for JACK and/or
plain ALSA, with expanded services via D-Bus, improved signal handling,
backward compatibility with previous APIs (including LADCCA), and other
amenities. LASH developer Dave
Manual provides more details for programmers. LASH became a popular
solution for complex sessions and is still found in many software
On to LADISH
LADISH — the Linux Audio Developers
Indefatigable?) Session Handler — is the current successor to the
LADCCA/LASH lineage. The project goals remain JACK-centric, with
sophisticated client identification according to "levels" that define the
detail of state storage and recall. D-Bus and jack-dbus are required, and
the LASH and JACK Session APIs are supported.
The concept of levels is neatly summarized in the LADISH documentation,
There are four levels of interaction between an application and the session handler.
- Level 0 — JACK application is not linked to a session handling
library (liblash, libladish). User has to save application projects
manually or rely on autosave support from application.
- Level 1 — JACK application is not linked to a session handling
library (liblash, libladish). Application saves when a UNIX signal is
- Level 2, LASH — JACK application is linked to liblash. Limited
interaction with session handler because of liblash API limitations.
- Level 2, JACK Session — JACK application uses JACK
Session. Limited interaction with session handler because of jack-session
- Level 3 — JACK application is linked to libladish. Full
interaction with session handler. Query room virtual ports.
L0 and L1 are implemented since ladish-0.2. L2 is implemented since
ladish-1, both LASH and JACK Session variants. L3 is still not implemented.
The use of these levels is an attempt to sort and regulate the various
possible conditions for any Linux audio application. Those conditions
include the degree of JACK compliance, any WINE or DOS requirements,
network operation, the multiplicity of existing APIs, and so forth.
Like the original LASH project, LADISH includes a GUI (called gladish)
for configuring LADISH and your session management
Gladish works perfectly, providing a neat concept of virtual
Studios, Rooms, and Projects for organizing your session components.
As an alternative, users
of the KXStudio system can
also choose to use its excellent Claudia utility, a custom-made
frontend for the LADISH System:
A "getting started with LADISH" tutorial is on-line at
the LADISH Wiki. Further
excellent tutorial material can be found at Lampros Liontos's
Producer web site.
The Non Session Manager
The Non Session Manager
is a component in the Non* suite of audio/MIDI software by Jonathan
Liles. It can be used as a standalone program without the rest of the
suite, but you will need to install the core NonToolKit library
first. Check your distribution's software repositories for an installable
Non suite. If it hasn't been packaged for your system, you'll have to visit
the Non Web site and follow the instructions there regarding access to the
project's Git repositories. The suite is easy to compile, with only a few
dependencies, all commonly found in any modern Linux distribution repositories.
After installing the program it's ready to run. The command-line invocation
takes two possible options, one to specify the URL of the Non Session
Manager daemon (nsmd) and one to indicate a particular root path for your
sessions. When the session manager starts, it requires no further
The Non Session Manager is easy to use. The top button bar exposes most of
its functions, though there are a few hidden features. The "New" button
starts a new session, "Add Client" adds an application to the session, "Save"
saves the session, and "Close" closes it. The "Open" button opens an existing
session, or you can click on the session name in the list box, where we
encounter hidden feature number one: clicking on the session name will
immediately close the running session and load your selection, so be sure
to save your work first. The "Duplicate" button copies a running session as a
template for later similar sessions.
When you add a client to a session you might discover another hidden
feature, the nsm-proxy client. This convenient feature
lets you add clients built without Non Session Manager or other session
management support, though the addition is limited to opening and closing
the particular client. If a client has LADISH level-1 support (or another
method of saving its internal state), you can also select a "Save State"
signal, though the Non Session Manager may not directly handle the state
Yet another hidden feature: When adding clients you can add a special
client named JACKPatch that will store your JACK audio and MIDI
connections. You can save a JACK connection map as a Patchbay in QJackCtl,
but of course you need to be running QJackCtl. The Non Session Manager
JACKPatch client provides a handy means of storing and restoring your
connections without an external application.
The Non Session Manager also has features of interest to users of networked audio
systems. Its documentation states that the Non Session Manager is the only
session manager capable of saving and restoring session configurations of
networked machines. Alas, I was unable to test a networked session, so I
must refer the reader to the Non Session Manager Web site for more
information regarding the handler's implementation over a network.
Of the session handlers I tested, the Non Session Manager gets
top honors for features, flexibility, ease of use, and transparency. It
does its job, otherwise it stays out of the way. It doesn't interfere with
other processes, and it can be reconfigured interactively during a
session. The Non Session Manager isn't perfect — I'd like to have a more
direct method of entering nsm-proxy clients, and I might like to be able to
rename sessions, but these are minor issues. Otherwise the Non Session
Manager is highly recommended Linux audio software.
The image below shows QJackCtl's JACK Session manager at work.
If your modular
configuration includes only JACK-compliant applications and you use
QJackCtl to manage connections, you might consider using it to manage your
sessions as well. Operation is simple enough — just click on the Session
button and follow the prompts for saving your work. The manager saves all
aspects of its clients and restores them exactly.
Incidentally, Ardour subscribes to the JACK session management protocol,
making it a simple matter to include its considerable powers into a modular
Programmer's documentation for the JACK session API can be perused
at jackaudio.org. For
normal users, the Tango Studio project has provided some excellent
documentation on its
Session tutorial page.
In my research for this article, I
discovered Chino, a scripted
session manager with no ties to previous management protocols. According to
its author, Chino is "... a framework and toolset to build and manage a
meta-application consisting of the user's favorite modular JACK audio and
MIDI tools, each started and interconnected in predefined ways." Chino's
developer is rather modest about his project, but I found it to be a
well-designed tool that may be just the item you need if the "heavier"
solutions don't suit your project requirements and you're comfortable with
the Linux command line.
Installation and configuration are covered in Chino's documentation. No
unusual dependencies are required, but you'll need the jack_snapshot
utility to store and recall your JACK audio and MIDI connections. You can
also save an SVG graphic display of your session's status. You'll need the
Xsvg viewer to view it from within a Chino session, though any SVG-capable
viewer can be used to view the image outside the session.
Chino defines a session in a method/application hierarchy. According to the
documentation, methods are "categories for applications that are to be
handled in similar ways. Every application belongs to one method."
Following that definition, the documentation informs us that applications
can be "(almost) anything... one or more (audio)-programs, audio/MIDI
hardware or netjack ports — many things can be crammed into an
application." In practice it's all simple enough. Start with this command
to start a new session:
chino -n newsession
Follow the prompts, and be sure to use the h (Help) and w
(Write) options liberally. You'll find your way around Chino quickly
If your saved session is named newsession.sdef you'll reopen it with this
chino -o newsession.sdef
Chino is easy to use and does its job quickly and efficiently. However, it
is still in development, with a few rough edges yet to polish. I created a test
session from its default settings for the amSynth and Yoshimi synthesizers,
with normal audio/MIDI connections made with QJackCtl. I saved the session,
but, on closing, amSynth had to be manually stopped. On reopening the session,
the synthesizers appeared as expected, but only amSynth's connections were
restored. I must emphasize that this is a single test case and in no way
stands as a general estimation. I'll need to spend some more time with
Chino — there's much more to it than what I've presented, and it is
definitely worth watching.
Summing the signals
When I started writing this article I had little experience with session
managers. I'm still no expert, still having a lot to learn about these
I'll hazard an opinion or two. Currently I prefer the Non Session Manager
for the greatest number of my projects. The LADISH-based handlers are
advised for sessions with only JACK-aware applications, though QJackCtl's
session handler may be preferred when using that utility. Chino is
available for command-line users, as is the humble and powerful bash scripting
Modular music systems are difficult to configure and restore, but by
definition what is difficult is not impossible. Apparently the developers
of these programs and utilities have a similar attitude towards difficult
things, and I'm happy to report the ever-improving states and conditions of
to post comments)