↹lature

From the README:

↹lature is a tracker-style DAW. Its most unique features include:

• First-class support for Open Sound Control
• CLAP plugin support
• Terminal UI
• Keyboard-focused workflow with Kakoune/vim style keybindings
• Headless mode for portable playback on a SBC or dedicated live performance machine
• A directly editable, git-friendly file format

motivation

Features that I want in a DAW:

• text-based save files
  • better git-friendliness
  • readable/editable in a text editor
• modal editing
  • first-class keyboard-only workflow
  • ideally in a TUI
• can play audio on a raspberry pi
• the features listed at the top of this article
• screen reader compatible
• package manager for parts that are non-redistributable due to copyright
• documentation for music (comments in the file, UI elements inline with the plugin chain where you can write stuff)
• capable of integrating a voice synthesizer into the software

Reaper comes really close, but I think only technically. I feel like it doesn't fulfill the spirit of text-editability, and the modal editing only comes with a plugins like reaper-keys or reaper-nvim. I think in order for a keyboard-only workflow to be actually usable, you have to really rethink what exactly the needs of a DAW are.

The subtext for all of these features is that fundamentally, I want this DAW to be one that panders to my every whim. No matter how ridiculous the feature, if it's something I want, it should be something this DAW does. If these requirements don't speak to you the way they speak to me, you're probably better off using Bitwig or Reaper (both very good DAWs that I still use!).

general design philosophy

• UI should be limited in scope to a few of the most heavily used parts of the interface
• similarly, common actions should be bound to the easiest keybinds, and uncommon actions should only be accessible by command line
• all actions should be accessible by a "scripting" language
• actions should be easy to type quickly for the "normal" case, but should be configurable (with optional parameters) for esoteric cases

prior art

FOSS DAWs

• SunVox
• web-synth
• BespokeSynth
• Zrythm
• Ardour
• HexoSynth
• ossia
• Radium
• neindaw

TUI music software

• Orca
• Cacophony (not technically TUI, but certainly TUI-esque)
• midiTracker
• any livecoding tool with a CLI REPL or a plaintext file format + hot reloading

trackers

• 1987 - the ultimate soundtracker
• 1989 - OctaMED
• 1994 - ScreamTracker 3
• 1995 - Impulse Tracker
• 1997 - OpenMPT
• 2002 - Renoise
• 2005 - MilkyTracker
• 2006 - SchismTracker
• 2008 - SunVox
• 2011 - DefleMask
• 2015 - FamiTracker
• 2018 - zytrax
• 2018 - sointu
• 2020 - Dirtywave M8
• 2020 - bintracker
• 2021 - Furnace
• 2024 - WaveTracker

devlog

Controller support

Controller support is implemented using JACK. I initially used midir, but I couldn't figure out how to synchronize notes within the buffer. While the approach that minimizes average latency would be for all the notes to trigger at the beginning of the audio frame, I have heard that psychoacoustically, stable jitter is more important to playability than latency. Plus, at large buffer sizes, having all the messages in a frame trigger at the beginning would likely be noticably distracting.

To implement this, I first add an additional port to the JackProcess struct:

pub struct JackProcess {
	// ...
	in_port_midi: jack::Port<jack::MidiIn>,
}

Then search for a controller and connect it to the port:

for ea_port in active_client.as_client().ports(None, Some("8 bit raw midi"), jack::PortFlags::IS_OUTPUT) {
	if ea_port.contains("HXCSTR") {
		log::debug!("found port {ea_port:?}");
		active_client.as_client().connect_ports_by_name(&ea_port, &format!("{}:midi_in", active_client.as_client().name()))
			.expect(&format!(r#"Could not connect ↹lature midi input to "{:?}"."#, ea_port));
	}
}

Lastly, read the input port in the process loop, adapting the push_event function that I use for auditioning cells:

for jack::RawMidi { time, bytes } in self.in_port_midi.iter(ps) {
	if bytes.len() == 3 {
		let msg = OscMessage {
			addr: "/HXCSTR".to_string(),
			args: vec![OscType::Midi(OscMidiMessage {
				port: 1,
				status: bytes[0],
				data1: bytes[1],
				data2: bytes[2],
			})],
		};
		pd.push_event_root((time as u64, msg));
	}
}

Note that the controller search and OSC message are hardcoded with the string "HXCSTR". Ideally, I'd have both a configurable method to automatically connect controllers as well as a manual menu system in the TUI to set up such connections.

I added controller support so I could practice playing HXCSTR, which unfortunately only supports MIDI at this point in time, but OSC support would likely be similarly trivial.

Chain view

Hypothetically, the entire audio graph can be represented as a list of nodes and the connections between them, where you can see each sound processor as a little "block", and their ports are routed explicitly into each other. However, most DAWs instead have a channel-based workflow, where sound processors are on one of many channels, and the audio from one flows into the next in the series. One of the driving forces that I think about when designing interfaces is to try to make the common use cases easy and clear, and relegate the uncommon use cases to more laborious and obscure parts of the interface. In the case of the audio graph, it is very common for signal chains to be considered on a per-instrument basis, where one set of notes is piped into an instrument processor followed by effect processors. This maps very neatly to the channel-based topology, and as such, I chose to try to preserve that in ↹lature.

The solution I came up with was the "chain", where a Block is a container for a series of Processors. I was struggling with a good way to draw the chain in a way that was scrollable, and this is one of the parts where making ↹lature TUI-based caused some friction in the implementation.

I mostly copied the default behavior of panning in [niri], but for those not familiar, in broad strokes, the requirements were these:

• The selected processor should always be fully visible (if possible)
• The chain view should not pan if it does not need to (including when blocks are deleted or resized)

I faffed about a bit for a working solution, but ended up with this:

let frame_width = f.size().width as i32;
// clamp cursor to chain length
self.cursor = self.cursor.min(constraints.len() - 1);
// get the x offset and width of currently selected processor
let cursor_x_offset = constraints.iter().take(self.cursor).sum::<u16>() as i32;
let cursor_width = constraints.get(self.cursor)
	.expect("bounds check should clamp cursor to a valid index of constraints");
// this calculation determines the view offset
self.offset = self.offset.clamp(cursor_x_offset + *cursor_width as i32 - frame_width, cursor_x_offset);

let mut idx_offset = 0;
let mut x_offset = 0;
// because it can be partially cut off, we must calculate the width of the leftmost visible processor
let first_width = loop {
	match constraints.get(idx_offset) {
		Some(width) => {
			x_offset += *width as i32;
			if x_offset > self.offset {
				break (x_offset - self.offset) as u16;
			}
			idx_offset += 1;
		}
		None => unreachable!("offset should not go past end of chain")
	}
};

CLAP TUI extension

source code

TODO: elaborate