History

The History of Non

Non Sequencer

The Non project began in 2006/2007 when I, Jonathan Moore Liles, started writing code for the Non Sequencer. From the very start, Non Sequencer (whose name is a terrible pun on Non Sequitur) was designed with the following goals in mind: Use JACK MIDI exlusively, be fast and light, and support the pattern/phrase/sequence model like that of Robobop on the Atari ST. However, in its earlest incarnation, the interface used the Lesstif GUI toolkit.

Below is a screenshot of the early Lesstif interface:

Prior to beginning Non Sequencer, I used seq24. At the time I was using Ardour and required a MIDI sequencer which could sync to the JACK transport. Seq24 worked ok, but it had a number of frustrating limitations. Among them:

1. A very slow and unattractive GTK GUI.
2. A many-windowed GUI.
3. A difficult to use GUI with cumbersome note placement method.
4. Lots of little icons the meaning of which is non-obvious.
5. No JACK MIDI support (only ALSA).
6. Flakey JACK transport slave support.
7. Pattern + song model required much copying and pasting for my compositions.

All of these combined to make my experience using Seq24 rather painful. Despite its claims to be simple and lightweight, I found the codebase of seq24 and its GTK GUI to be formidably overcomplicated. Rather than attempt to improve seq24, I decided to rewrite my own sequencer from scratch. Starting in pure C and using the Lesstif toolkit, and eventually migrating to FLTK and C++, I was soon relying on Non Sequencer for all of my MIDI work. Once my basic needs had been met, development on Non Sequencer slowed as I got back to making music.

Non DAW

In 2007/2008, I was using Ardour together with Non Sequencer for my music production. I became increasingly frustrated with Ardour for a number of reasons. Among them:

1. It was a resource hog that took so long to start up it required a splash screen.
2. It had many memory corruption bugs that would routinely result in corrupt session files.
3. It would allow LADSPA plugins to crash the session and/or corrupt the session files (through memory corruption).
4. It was slow to 'save' projects, but you had to 'save' a lot if you didn't want to lose your data.
5. The new GTK2 GUI was very slow.
6. The performance deteriorated rapidly as more tracks/regions were added.
7. The only way to have looped regions was to duplicate the region X number of times, which compounded the above.
8. A truly massive and overly complicated codebase.
9. A fractal interface which duplicated functionality should belong to JACK (signal routing).

After losing yet another session to a memory corruption bug and spending weeks searching in vain for the cause in the Ardour codebase, I decided it was time to try another DAW. I experimented with QTractor, Traverso and a few other DAW-like things and found them all to be woefully inadequate in comparison to Ardour. I figured that it would take me half a decade or more to fix all of the architectural and performance problems in Ardour, or half a year to write my own DAW from scratch. I decided to do the latter. Thus was born Non DAW.

I had learned FLTK pretty well in writing Non Sequencer, so Non DAW development proceeded smoothly. Sure enough, in about 6 months I had a program with most of the functionality I needed, but, most importantly, it was a program that was stable, reliable, fast, lightweight, and with a simple and small codebase--all of the things that Ardour was not.

Below is a screenshot of that early interface:

A large part of the development time of Non DAW was spent working around FLTK's 16-bit limit on widget dimensions and playing around with a completely separate engine and GUI connected via a mostly ASCII TCP protocol (later abandoned because of the bandwidth demands of transporting waveform peak data).

Once Non DAW had reached a usable state, I ditched Ardour entirely (never looking back) and started using Non DAW and Non Sequencer together with a stand-alone mixer program called LiveMix.

LiveMix had a (rather slow) QT GUI and the ability to host LADSPA plugins. However, it was missing the ability to accept external control of the plugin parameters. For this I had to use SpiralSynthModular, which could accept external Control Voltage like signals via JACK audio ports and use them to control plugin parameters. However, SSM was a bit crashy and its manual routing was a pain for complex mixes.

Non Mixer

In 2008/2009 I began work on Non Mixer with the goal of replacing the functionality I was relying on SpiralSynthModular for with a more usable interface and stable engine. True to my modular inclinations, I wanted to keep the mixer completely separate from Non DAW and usable as stand-alone program.

I was interested in using Ambisonics technology in my mixes at the time, but found dealing with them to be rather cumbersome, so I went the extra mile and included a special support for the Ambisoncs LADSPA panner plugins in Non Mixer.

Non Mixer was released in early 2010.

Below is a screenshot of the early interface:

Non Session Manager

Way back in 2008, I became frustrated with the state of the art of session management on Linux (a situation which has improved only incrementally since that time). I ditched support for LASH, wrote a lengthy post about Non-DAW's session management requirements to the LAD mailing list, and started managing my sessions with shell scripts and jack_snapshot. This eventually evolved into a session manager written in Unix shell and using Unix FIFOs and regular files for client control/communication. This system of session management was tentatively called NASH (Non Audio Session Handler) and was never released. In 2010, shortly after the release of Non-Mixer, I devised a prototype version of the NSM OSC API and have been using it, still unreleased and in prototype form, since then. The 2010 implementation did not have a user interface and was controlled via shell scripts using the `send_osc` command included in the distribution. Then, in 2012 (4 years later!), I was contacted by an enthusiastic power-user regarding implementing OSC support in Non-Mixer. Since NSM uses OSC for server<->client communication, I already had much of the OSC work done and figured I might as well release it--and, while I was at it, NSM. I then endeavored to simplify and document the NSM API, discussing it at length with, and taking many suggestions from, Nedko Arnaudov, the LADISH author. After implementing the Non-Session-Manager FLTK GUI to control the session management daemon, a new release became inevitable.

NTK

...