DEV Community: suntong

Qtractor Usage Bible - Volume 3

suntong — Wed, 17 Jun 2026 00:38:27 +0000

Volume 3 — Session Management

PART III — SESSION MANAGEMENT

Chapter 8 — Creating and Organizing Projects

The Session As The Studio

Everything inside Qtractor begins with a session.

A session is not merely a project file.

A session is the complete description of:

timeline structure
track layout
clip placement
routing
plugins
automation
tempo information
markers

A useful mental model is to regard a session as a virtual studio.

Opening a session reconstructs the studio exactly as it existed when saved.

Creating A New Session

Creating a session involves more than naming a file.

Several decisions made at creation time affect the entire production.

Typical information includes:

session name
session directory
sample rate
tempo
time signature

Although some values can later be changed, establishing them correctly at the beginning reduces complications.

Session Naming

Good naming practices become increasingly important as project count grows.

Poor:

song
song2
song-final
song-final-final

Better:

2026-06-16_MySong
2026-06-16_MySong_v01

Best:

Artist_TrackName_20260616

Consistent naming simplifies:

backups
collaboration
archival retrieval

Session Directories

Every session should have its own dedicated directory.

Typical structure:

MySong/

 ├── MySong.qtr
 ├── audio/
 ├── midi/
 ├── exports/
 ├── backups/
 └── notes/

A dedicated directory prevents:

missing files
accidental overwrites
organizational chaos

Why Separate Sessions Matter

Mixing multiple projects inside one directory often causes:

duplicate filenames
lost recordings
broken references

One project equals one directory.

This principle remains useful regardless of project size.

Planning Before Recording

Many editing problems originate before recording begins.

Before creating tracks, establish:

Song Structure

Example:

Intro
Verse
Chorus
Verse
Chorus
Solo
Outro

Expected Track Count

Example:

Lead Vocal
Backing Vocal
Guitar L
Guitar R
Bass
Kick
Snare
OH L
OH R

Routing Requirements

Example:

Drum Bus
Vocal Bus
FX Bus
Master Bus

Instrument Requirements

Example:

Piano
Strings
Synth Pad

Planning reduces future reorganization.

Session Templates

Templates eliminate repetitive setup.

Instead of rebuilding the same studio repeatedly, a prepared configuration becomes the starting point.

Example Podcast Template

Host
Guest
Music
FX

Master

Example Singer-Songwriter Template

Vocal
Acoustic Guitar
Room Mic

Reverb Bus
Master

Example MIDI Production Template

Drums
Bass
Piano
Strings
Brass

Master

Templates improve:

consistency
efficiency
organization

Track Naming Conventions

Track names should immediately communicate purpose.

Poor:

Audio 1
Audio 2
Audio 3

Good:

Lead Vocal
Backing Vocal
Ac Guitar
Bass DI

The larger the project becomes, the more valuable clear naming becomes.

Color Organization

Color assignment helps identify track categories.

Example:

Red      Vocals
Blue     Drums
Green    Guitars
Purple   Keyboards
Yellow   FX

The objective is rapid visual identification.

Organizing Large Sessions

As track count increases:

10 tracks
20 tracks
50 tracks
100+ tracks

organization becomes increasingly important.

Common strategies include grouping by:

Instrument Family

Drums
Bass
Guitars
Keys
Vocals

Signal Flow

Sources
Groups
FX
Masters

Recording Order

Rhythm
Harmony
Lead
Effects

Any consistent strategy is preferable to none.

Chapter 9 — Session Files And Data Structures

Understanding The .qtr File

The primary Qtractor session file uses:

.qtr

extension.

Internally it is XML.

The file contains instructions rather than media.

What The .qtr File Stores

Examples:

Tracks
Plugins
Routing
Markers
Automation
Clip Locations

What The .qtr File Does Not Store

Examples:

Audio recordings
Large WAV files
FLAC files

The media remains separate.

Why This Matters

A session file may be:

300 KB

while referenced audio consumes:

3 GB

Copying only the .qtr file does not copy the project.

Understanding References

Suppose:

vocals.wav

exists.

The session records:

Use vocals.wav

Start:
00:01:05

End:
00:01:12

The session references the file.

It does not contain the file.

Relative Paths

Relative paths are generally preferable.

Example:

audio/vocals.wav

instead of:

/home/user/projects/song/audio/vocals.wav

Relative paths improve portability.

Why Absolute Paths Cause Problems

Moving the project directory may produce:

Missing File

errors.

The session still expects the old location.

Understanding Session Saves

Saving stores:

current arrangement
current routing
current plugins
current automation

Saving does not necessarily rewrite media files.

Save Versus Save As

Save

Updates current session.

Save As

Creates new session version.

Useful for:

Song_v01
Song_v02
Song_v03

Version-Based Workflow

Professional projects often use incremental versions.

Example:

MySong_v01.qtr
MySong_v02.qtr
MySong_v03.qtr

Advantages:

experimentation
rollback
protection against mistakes

Milestone Saving

A useful habit is saving before major operations.

Examples:

Before Editing

v05

Before Mixing

v10

Before Mastering

v20

This creates recovery points.

The .qtz Archive Format

Qtractor supports:

.qtz

archives.

A qtz archive packages session information together.

Purpose Of QTZ

Designed for:

portability
backup
transfer

The archive acts as a bundled project package.

When To Use QTZ

Useful before:

moving projects
sharing projects
long-term storage

When Not To Rely Solely On QTZ

Working projects generally benefit from ordinary directory structures.

The archive serves best as:

snapshot
backup
delivery package

Chapter 10 — Asset Management

What Is An Asset?

Assets include:

recordings
imported audio
MIDI files
stems
loops

Everything used by the session becomes an asset.

The Files Panel

The Files panel functions as the project's asset inventory.

Many users focus exclusively on the timeline and ignore the Files panel.

Doing so often creates organizational problems later.

Audio Tab

Displays available audio resources.

Examples:

vocals.wav
guitar.wav
drums.wav

MIDI Tab

Displays MIDI resources.

Examples:

strings.mid
piano.mid
drums.mid

Importing Assets

Assets may be imported from external sources.

Examples:

Loop libraries
Field recordings
Sample packs
External sessions

After import, they become available for placement on tracks.

Asset Reuse

One asset may appear many times.

Example:

Chorus.wav

used at:

01:00
02:00
03:00

No duplication occurs.

Only references are added.

Benefits Of Reuse

Advantages:

reduced disk usage
simplified editing
efficient arrangement building

Orphaned Assets

An orphaned asset exists within the project but is no longer used.

Example:

old_vocal_take.wav

remaining after editing.

Why Orphaned Assets Matter

Large projects accumulate:

unused takes
abandoned recordings
obsolete stems

Storage consumption gradually increases.

Session Cleanup

Periodic cleanup improves:

organization
portability
backup efficiency

Common cleanup activities:

Remove Unused Takes

Remove Test Recordings

Remove Temporary Exports

Consolidate Naming

Verify Asset Locations

Naming Assets

Poor:

audio0001.wav
audio0002.wav

Better:

LeadVocal_Take01.wav
LeadVocal_Take02.wav

Clear naming reduces confusion during editing and recovery.

Chapter 11 — Backup, Versioning & Archival

Why Backup Matters

Projects often represent:

days
weeks
months

of work.

A backup strategy should exist before significant production begins.

Three Types Of Protection

A complete protection strategy includes:

Session Protection

Protects arrangement data.

Asset Protection

Protects recordings.

Archive Protection

Protects completed projects.

Versioning

Versioning provides insurance against mistakes.

Rather than overwriting endlessly:

song.qtr

maintain:

song_v01.qtr
song_v02.qtr
song_v03.qtr

Major Revision Strategy

Increment versions when:

Editing Completed

Mixing Started

Routing Redesigned

New Recordings Added

Plugins Replaced

This creates meaningful checkpoints.

Backup Directory Structure

Example:

Project

 ├── Current
 ├── Backups
 ├── Exports
 └── Archives

Keeping backups separate improves safety.

Portable Project Verification

Before moving a project:

Verify:

Audio Present

MIDI Present

Plugins Available

Missing Files Resolved

Exports Completed

Session Loads Correctly

Long-Term Archival

The goal of archival is future accessibility.

Future systems may not possess:

identical plugins
identical operating systems
identical instruments

For this reason archival should include:

Session Files

Raw Audio

MIDI Files

Final Mixes

Stem Exports

Documentation

Recommended Archive Package

Project/

 ├── Session
 ├── Audio
 ├── MIDI
 ├── Stems
 ├── Final Mix
 └── Notes

This structure maximizes the probability of successful future recovery.

Session Management Checklist

Before serious production begins:

✓ Dedicated project directory

✓ Consistent naming

✓ Template selected

✓ Backup strategy established

✓ Versioning strategy established

✓ Asset organization planned

✓ Marker strategy planned

✓ Routing structure planned

A well-managed session reduces editing mistakes, accelerates production, simplifies collaboration, and significantly improves the long-term survivability of a project.

Volume 3 Complete

Next Volume: Audio Recording
(Track creation, input assignment, mono/stereo recording, monitoring, takes, overdubbing, punch recording, loop recording, gain staging, clipping prevention, comping workflows, and recording best practices.)

Qtractor Usage Bible - Volume 2

suntong — Wed, 17 Jun 2026 00:26:10 +0000

PART II — USER INTERFACE & DAILY OPERATION

Chapter 4 — Main Window Architecture

The Workspace Philosophy

The Qtractor interface revolves around a single principle:

everything eventually exists somewhere on the timeline.

Whether recording audio, programming MIDI, arranging a song, mixing stems, or exporting a final master, all operations ultimately relate to a position in time.

The interface therefore prioritizes visibility of:

timeline position
track organization
clip placement
transport status
signal routing

Unlike DAWs that separate composition, mixing, and editing into radically different workspaces, Qtractor keeps most production activities inside a unified session view.

Main Window Overview

The main window consists of several major regions:

+--------------------------------------------------+
| Menu Bar                                         |
+--------------------------------------------------+
| Toolbars / Transport Controls                    |
+--------------------------------------------------+
| Timeline Ruler                                   |
+--------------------------------------------------+
| Track List      |      Track Timeline Area       |
|                 |                               |
|                 |                               |
|                 |                               |
+--------------------------------------------------+
| Status Bar                                       |
+--------------------------------------------------+

Optional panels may appear around the workspace:

Files
Mixer
Connections
Messages
Markers
Tempo maps
Patchbay

The exact arrangement depends upon workspace preferences.

Menu Bar

The menu bar provides access to all functionality.

Important menus include:

File

Session operations:

New
Open
Save
Save As
Import
Export

Edit

Timeline editing operations:

Cut
Copy
Paste
Delete
Select
Split
Merge

Track

Track creation and management.

Examples:

Add Track
Remove Track
Duplicate Track
Move Track

View

Visibility and workspace layout.

Examples:

Mixer
Files
Connections
Markers
Toolbars

Transport

Playback control.

Examples:

Play
Stop
Record
Loop
Locate

Clip

Clip-level editing.

Examples:

Normalize
Split
Merge
Properties

Track

Track-specific operations.

Plugins

Plugin management.

Options

Session behavior and editing preferences.

Toolbars

Toolbars expose frequently used functions.

Common controls include:

New Session
Open Session
Save Session
Undo
Redo

as well as transport controls.

Toolbars may be shown or hidden independently.

Large monitors often benefit from expanded toolbars.

Smaller displays often benefit from a minimal layout.

Transport Section

Transport controls govern movement through the timeline.

The transport area typically contains:

Play
Stop
Record
Rewind
Fast Forward
Loop Toggle

and position indicators.

Playhead Position

The playhead represents the current time location.

Everything references this location:

playback
recording
insertion
paste operations

Many editing actions occur at the playhead.

Developing awareness of playhead position becomes one of the most important editing habits.

Timeline Ruler

The ruler forms the backbone of the session.

It displays either:

Time

00:00:00
00:01:00
00:02:00

Musical Time

1|1|000
2|1|000
3|1|000

depending upon project requirements.

Track List

The left side contains track headers.

Each track header contains:

Name
Mute
Solo
Record
Monitor
Input Assignment
Output Assignment

Track headers control entire tracks rather than individual clips.

This distinction becomes important during editing.

Track Timeline Area

The largest region of the screen contains clips.

Audio clips appear as waveforms.

MIDI clips appear as blocks.

This area supports:

selection
movement
trimming
splitting
arranging

Most production work occurs here.

Files Panel

One of the most important panels in Qtractor.

Many beginners overlook it.

The Files panel acts as a project asset manager.

It contains references to:

Audio Files

Examples:

vocals.wav
guitar.wav
ambience.wav

MIDI Files

Examples:

drums.mid
strings.mid

The Files panel allows rapid insertion of assets into the session.

It also provides visibility into project resources.

Mixer Window

The mixer presents tracks as channel strips.

The mixer emphasizes:

levels
panning
sends
plugins

while the timeline emphasizes arrangement.

Both views represent the same session from different perspectives.

Status Bar

The status bar communicates:

current operation
selection information
cursor position
editing context

Important messages often appear here before becoming visible elsewhere.

Chapter 5 — Navigation & Timeline Control

Moving Through Time

Efficient navigation becomes increasingly important as projects grow.

Small projects may contain:

several tracks
a few minutes of audio

Large projects may contain:

dozens of tracks
hundreds of clips
multiple movements

Without effective navigation, editing speed collapses.

The Playhead

The playhead represents the current position.

Clicking inside the ruler typically relocates it.

Playback begins from the playhead.

Paste operations frequently occur at the playhead.

Recording often begins at the playhead.

Understanding where the playhead sits prevents countless editing mistakes.

Locating Positions

Several methods exist:

Direct Click

Fastest method.

Click the ruler.

Playhead jumps immediately.

Transport Controls

Move sequentially.

Useful during playback.

Marker Navigation

Jump between important positions.

Often the fastest approach in large projects.

Zooming

Two dimensions exist:

Horizontal Zoom

Controls time visibility.

Useful for:

detailed editing
waveform inspection
precision cuts

Vertical Zoom

Controls track visibility.

Useful for:

large track counts
waveform inspection
MIDI editing

Editing efficiency depends heavily on selecting the appropriate zoom level.

Markers

Markers identify important locations.

Examples:

Intro
Verse
Chorus
Bridge
Solo
Outro

Markers transform navigation from time-based thinking into structure-based thinking.

Creating Markers

Common methods include:

Marker menu commands
Context menu operations
Dedicated marker panels

A marker is created at the current playhead location.

Naming Markers

Meaningful names provide substantial benefits.

Good:

Verse 1

Poor:

Marker 17

Large sessions often contain dozens of markers.

Meaningful naming prevents confusion.

Removing Markers

Markers may be removed through:

Marker panel
Context menu
Marker editing dialog

Removing a marker affects navigation only.

Media remains unchanged.

Locators

Locators define regions.

Two locator points exist:

Left Locator

Region start.

Right Locator

Region end.

Together they define:

|<------Region------>|

Practical Uses of Locators

Loop Playback

Repeated playback of a section.

Useful for:

mixing
practicing
editing

Punch Recording

Record only inside a region.

Export Regions

Render selected sections.

Focused Editing

Concentrate on a specific passage.

Preventing Endless Playback Beyond the Song

One common annoyance occurs when playback continues far beyond meaningful content.

The transport proceeds through empty space.

This wastes time and disrupts workflow.

Several approaches solve this.

Method 1 — Loop Region

Place locators around the song.

Enable looping.

Playback returns automatically.

Method 2 — Session-End Marker

Place a clearly named marker:

END

at the final musical event.

Navigation remains predictable.

Method 3 — Export-Oriented Locators

Maintain permanent start and end locators matching the intended song length.

Many engineers adopt this as standard practice.

Timeline Selection

Selections determine what editing commands affect.

Selection context is one of the most important concepts in Qtractor.

Chapter 6 Part 1 — Editing Fundamentals, Selections, Clips, and Everyday Audio Operations

Understanding What Actually Gets Edited

One of the most common sources of confusion in Qtractor is determining what exactly is being edited at any given moment.

A session contains several different kinds of objects:

Session
 ├── Tracks
 │     ├── Clips
 │     ├── Plugins
 │     └── Automation
 └── Busses

Most editing operations occur on one of three levels:

Track level
Clip level
Time-range (region) level

Understanding which level is currently active determines what happens when moving, deleting, copying, trimming, or processing material.

Understanding Tracks

A track is a container.

A track itself does not contain audio data.

Instead, it provides:

recording destination
playback lane
plugin chain
mixer controls
routing information
automation

For example:

Vocal Track
 ├── Clip 1
 ├── Clip 2
 ├── Compressor
 ├── EQ
 └── Volume Automation

The track acts like a channel strip combined with a timeline lane.

What Happens When A Track Is Selected

A selected track becomes the current target for track-level operations.

Typical operations include:

renaming
deleting
duplicating
changing routing
assigning plugins
enabling recording

Track selection does not automatically select clips.

Visual Clues For Track Selection

A selected track usually displays:

highlighted track header
highlighted track name area
visual emphasis compared to other tracks

The exact appearance varies slightly depending upon theme.

The easiest indicator is usually the highlighted track header on the left side.

Why Select A Track?

Track selection is useful when working with:

Routing

Changing inputs.

Changing outputs.

Changing bus assignments.

Plugin Management

Adding:

EQ
Compressor
Reverb
Synthesizer

Recording

Arming tracks.

Changing monitoring.

Changing recording behavior.

Automation

Creating automation lanes.

Why Track Selection Is Not Enough For Editing

Suppose a vocal track contains:

Track
 ├── Verse
 ├── Chorus
 ├── Outro

Selecting the track alone does not indicate which clip should move.

Moving requires clip selection.

Understanding Clips

A clip is the actual object placed on the timeline.

A clip references content.

Audio clip:

Verse.wav

MIDI clip:

Notes + Controllers

A clip occupies:

Start Time
Duration
Track Position

A track can contain many clips.

Clip Versus Recording

A clip is not necessarily a recording.

Examples:

Recorded Clip

vocal_take01.wav

Imported Clip

drum_loop.wav

Copied Clip

Multiple clips may reference the same source file.

Verse.wav

Clip A
Clip B
Clip C

Only one actual audio file exists.

Visual Clues For Clip Selection

A selected clip normally displays:

highlighted border
highlighted fill
resize handles
visual emphasis

Exact appearance depends upon theme.

A selected clip always stands out from surrounding clips.

Single Clip Selection

Click once on the clip.

The clip becomes selected.

Operations now affect:

that clip
only that clip

Multiple Clip Selection

Multiple clips may be selected.

Common methods:

Ctrl-click

Add clips one by one.

Drag Selection Box

Draw around clips.

Useful for large arrangements.

Select Entire Region

Select many clips spanning time.

Why Select A Clip?

Clip selection enables:

Moving

Before

| Clip |

After

          | Clip |

Copying

Original

| Clip |

Copy

| Clip |      | Clip |

Splitting

Before

|----------|

After

|----|----|

Trimming

Before

|----------|

After

   |----|

Fading

Fade In

/-------

Fade Out

-------\

Clip Properties

Adjust:

gain
pan
pitch
stretch

without affecting the track itself.

Clip Selection Versus Track Selection

This distinction is extremely important.

Suppose:

Track A
  Clip 1
  Clip 2

Track B
  Clip 3

Selecting Track A means:

Track A selected

Editing commands target the track.

Selecting Clip 2 means:

Clip 2 selected

Editing commands target Clip 2.

Many accidental edits occur because:

Track intended.

Clip selected.

Clip intended.

Track selected.

Understanding Regions

A region is a time selection.

Not a clip.

Not a track.

A region defines:

Start Time
End Time

Example:

00:10
to
00:20

Regions are useful for:

copying song sections
deleting sections
loop playback
focused editing

Recording Audio

Preparing A Track For Recording

The normal workflow:

Step 1

Create an audio track.

Step 2

Assign input.

Example:

Input 1

from interface.

Step 3

Arm recording.

Record button becomes active.

Step 4

Enable monitoring if required.

Step 5

Start recording.

Mono Versus Stereo Recording

Many beginners accidentally record stereo when mono is desired.

Mono Recording

Typical sources:

microphone
guitar
bass

Single channel:

Input 1

Result:

Mono Clip

Smaller file.

Correct source representation.

Stereo Recording

Typical sources:

keyboards
stereo synths
stereo mixers

Two channels:

Input 1 + Input 2

Result:

Stereo Clip

Why Mono Often Makes More Sense

A vocal microphone is inherently mono.

Recording:

Left = Voice
Right = Silence

creates waste.

Mono is cleaner.

More flexible.

Consumes less storage.

Recording Levels

Recording quality depends heavily upon level management.

Too Quiet

Problems:

poor signal-to-noise ratio
increased noise after amplification

Too Loud

Problems:

clipping
distortion
unrecoverable damage

Good Recording Range

Modern digital recording benefits from leaving headroom.

Peak values roughly around:

-18 dBFS
to
-6 dBFS

are usually comfortable.

There is rarely a need to record near 0 dBFS.

Understanding Clipping

Clipping occurs when signal exceeds maximum digital level.

0 dBFS

The waveform becomes flattened.

Visual Appearance

Healthy waveform:

 /\      /\
/  \    /  \

Clipped waveform:

 ____      ____
|    |____|    |

The tops become squared.

Why Clipping Is Bad

Information is destroyed.

Not merely hidden.

Destroyed.

Once severe clipping occurs, perfect restoration is impossible.

Fixing Clipping During Recording

Best solution:

Prevent it.

Lower:

interface gain
microphone preamp gain
source level

before recording.

Fixing Existing Clipping

Severity determines outcome.

Mild Clipping

May be improved using:

declippers
restoration tools
waveform repair

Usually external tools.

Severe Clipping

Recovery becomes limited.

Often re-recording is preferable.

What If Only One Section Is Too Loud?

Suppose:

Verse = good

Chorus = too loud

Several options exist.

Clip Gain

Split the clip.

Verse | Chorus

Reduce gain only on chorus section.

Automation

Create volume automation.

Reduce problematic region.

Compression

Control peaks.

Useful when clipping occurred after recording but before mixing.

Important Distinction

Reducing gain after recording does NOT repair clipped recording.

It only lowers playback volume.

If clipping already exists inside the recorded waveform, the damage remains.

Clip Gain

Clip gain affects one clip only.

Example:

Clip A = +3 dB

Clip B = -6 dB

Same track.

Different levels.

This differs from track volume.

Track Volume

Track volume affects everything on the track.

Clip A
Clip B
Clip C

all become louder or quieter.

When To Use Clip Gain

Use clip gain when:

One clip differs from surrounding clips.

Example:

Interview

One speaker much louder.

Adjust clip.

Leave track alone.

When To Use Track Volume

Use track volume when:

Entire track is too loud.

Example:

Whole vocal track

needs reduction.

Clip Normalization

Normalization is frequently misunderstood.

What Normalization Does

Normalization scans the clip.

Finds the loudest sample.

Then amplifies entire clip so that sample reaches target level.

Example:

Peak = -12 dBFS

Normalize to:

-1 dBFS

Entire clip gains:

+11 dB

What Normalization Does Not Do

It does not:

improve performance
improve tone
repair clipping
compress dynamics

Example

Original:

Peak = -20 dBFS

Normalize.

Result:

Peak = -1 dBFS

Everything becomes louder.

Dynamics remain identical.

When Normalization Helps

Useful when:

recordings are excessively quiet
preparing spoken-word clips
imported files have inconsistent levels

When Normalization Should Be Avoided

If mixing is already underway.

If levels are already appropriate.

If clipping exists.

Normalization is not a repair tool.

Everyday Editing Workflow

A typical editing pass often follows this order:

1

Create markers.

2

Select clips.

3

Split mistakes.

4

Delete unwanted sections.

5

Trim boundaries.

6

Create fades.

7

Adjust clip gain.

8

Move clips into position.

9

Verify locator boundaries.

10

Begin mixing.

This workflow forms the foundation of most practical Qtractor editing sessions, regardless of whether the material consists of vocals, instruments, podcasts, audiobooks, or MIDI-based productions.

Chapter 6 Part 2 — Editing Tools & Selection Mechanics

Understanding Selection Context

Qtractor always operates on a current selection.

A command affects:

selected clips
selected tracks
selected regions

depending upon what is currently active.

Most editing mistakes originate from misunderstanding the current selection.

Clip Selection

Selecting a clip activates clip-level editing.

Operations include:

move
copy
cut
delete
trim
split

Only selected clips are affected.

Multiple Clip Selection

Multiple clips may be selected simultaneously.

Useful for:

moving arrangements
copying sections
deleting phrases

Large arrangement edits often rely heavily upon multi-selection.

Track Selection

Selecting a track activates track-level operations.

Examples:

track deletion
track duplication
routing changes

Track selection differs fundamentally from clip selection.

Region Selection

Some operations affect a time range rather than individual clips.

Examples:

copy a chorus
remove silence
duplicate a section

Region-based editing becomes increasingly important in arrangement work.

Moving Clips

The most common editing operation.

A selected clip may be dragged:

left
right
between tracks

depending upon workflow requirements.

Timing Preservation

Careful movement preserves rhythmic alignment.

Grid snapping often assists.

Copying Clips

Copy creates additional references.

Original material remains.

Copied clips may be:

moved
edited
rearranged

without affecting source recordings.

Cutting Clips

Cut performs:

copy
remove

The removed material enters the clipboard.

Pasting Clips

Paste inserts clipboard contents.

The insertion point typically follows:

playhead position
current selection

depending upon context.

Awareness of insertion location prevents accidental duplication.

Deleting Clips

Delete removes clip references.

Source media remains intact.

This distinction is critical.

Deleting a clip does not delete the recording itself.

Splitting Clips

Splitting divides a clip into independent segments.

Example:

Before:

[-----------]

After:

[-----][-----]

Common uses:

removing mistakes
creating edits
rearranging phrases

Trimming Clips

Trimming adjusts visible boundaries.

The underlying recording remains available.

This permits:

recovery of trimmed material
experimentation
non-destructive editing

Arranging Song Sections

Large edits often occur at the arrangement level.

Examples:

Duplicate Chorus

Select chorus clips.

Copy.

Paste later.

Remove Verse

Select verse region.

Delete.

Close resulting gap if desired.

Extend Outro

Copy final phrase.

Paste repeatedly.

Track Operations

Entire tracks may be:

renamed
duplicated
reordered
deleted

These operations affect organization rather than media content.

Reordering Tracks

Track order affects:

visual organization
mixer organization
workflow efficiency

Track order does not inherently alter audio timing.

Practical Arrangement Workflow

A common arrangement process:

Record material.
Create markers.
Define song sections.
Duplicate useful sections.
Remove weak sections.
Refine transitions.
Verify locator boundaries.

Markers and locators dramatically accelerate this process.

Chapter 7 — Workspace Customization

(Continued in Volume 3)

Qtractor Usage Bible - Volume 1

suntong — Wed, 17 Jun 2026 00:19:05 +0000

QTRACTOR BIBLE

Volume 1 — Foundations

PART I — QTRACTOR CONCEPTS & WORKFLOW MODEL

Chapter 1 — What Qtractor Is

Quick Start

Qtractor is a non-destructive, multi-track audio and MIDI sequencer designed primarily for Linux-based production environments.

Unlike applications that attempt to integrate every aspect of the audio ecosystem into a single package, Qtractor focuses on recording, sequencing, editing, routing, mixing, and rendering while cooperating with external audio infrastructure and specialized tools.

Qtractor is best understood as a timeline-centered production environment where audio clips, MIDI clips, plugins, automation, and routing configurations are organized into sessions.

Common uses include:

Music production
MIDI composition
Podcast production
Voice recording
Sound design
Film scoring
Hybrid hardware/software studios
Live backing-track preparation

Design Philosophy

Qtractor follows several fundamental principles:

Non-Destructive Editing

Source media files remain unchanged.

When a clip is trimmed, split, faded, moved, stretched, or processed, Qtractor modifies references and parameters rather than rewriting the original recording.

Benefits include:

Unlimited experimentation
Reversible editing
Reduced storage requirements
Safer project management

Session-Based Workflow

Every operation belongs to a session.

A session contains:

Track definitions
Clip placements
Bus configurations
Plugin assignments
Automation data
Routing information
Tempo maps
Markers

Audio and MIDI source files remain separate from session instructions.

Timeline-Centered Production

The timeline is the primary workspace.

Nearly every task ultimately relates to a position on the timeline:

Recording
Editing
Automation
Arrangement
Export

Qtractor is optimized for linear productions rather than clip-launching performance systems.

Open Ecosystem Integration

Qtractor assumes cooperation with:

Audio servers
MIDI systems
External synthesizers
External samplers
Video playback tools
Modular audio environments

Rather than replacing these tools, Qtractor coordinates them.

Typical Production Workflows

Audio Recording

Examples:

Vocals
Guitars
Drums
Narration
Podcasts

Workflow:

Create tracks
Assign inputs
Record takes
Edit performances
Mix
Export

MIDI Composition

Examples:

Orchestral scoring
Electronic music
Soundtrack production

Workflow:

Create MIDI tracks
Assign instruments
Record or program notes
Edit performances
Automate parameters
Render audio

Hybrid Studios

Examples:

Hardware synthesizers
Drum machines
External effects

Workflow:

Route MIDI outward
Receive audio returns
Record performances
Mix alongside software instruments

Strengths

Lightweight Resource Usage

Qtractor typically consumes fewer resources than many large DAWs.

Advantages:

Older hardware compatibility
Mobile systems
Small studio computers
Reduced startup times

Strong MIDI Capabilities

Qtractor was originally designed with significant MIDI functionality.

Features include:

Piano roll editing
Controller editing
Quantization
Instrument definitions
Multi-channel routing

Flexible Routing

The routing architecture supports:

Multiple busses
Auxiliary sends
Sidechains
Hardware integration
Multi-output instruments

Linux Ecosystem Compatibility

Qtractor integrates well into Linux audio production environments and interoperates with many common Linux audio tools.

Limitations

Understanding limitations prevents workflow frustration.

Linear Arrangement Focus

Qtractor is optimized for timeline-based production.

Applications focused on clip launching, scene launching, or performance grids may be more suitable for certain live-production workflows.

No Integrated Audio Restoration Suite

Tasks such as:

Spectral repair
Noise profiling
Advanced restoration

typically require external tools.

External Dependency Philosophy

Many studio functions may rely upon:

External instruments
External synthesizers
External synchronization sources

This design is intentional.

Everyday Usage

A typical Qtractor session proceeds through six stages:

Stage 1 — Create Session

Establish:

Tempo
Tracks
Busses
Project structure

Stage 2 — Capture Material

Record:

Audio
MIDI

or import existing media.

Stage 3 — Edit Material

Refine performances through:

Trimming
Splitting
Quantization
Timing correction

Stage 4 — Arrange

Construct song structure using:

Sections
Repetition
Layering

Stage 5 — Mix

Balance:

Levels
Panning
Effects
Dynamics

Stage 6 — Deliver

Export:

Stereo mixes
Stems
MIDI files

Internal Perspective

Internally, Qtractor functions as a coordinator of:

Media references
Time positions
Routing relationships
Plugin states
Automation data

The session file describes what should happen.

The audio engine executes those instructions in real time.

Chapter 2 — Understanding the Qtractor Project Model

Quick Start

Everything inside Qtractor can be understood through seven core objects:

Session
Track
Clip
Bus
Plugin
Connection
Automation

Understanding these objects explains nearly every feature in the application.

The Session

A session is the top-level container.

It defines:

Timeline
Tempo map
Tracks
Busses
Plugins
Routing
Markers
Automation

Think of the session as the complete production.

Session Contents

A session typically stores:

Element	Stored
Track definitions	Yes
Clip locations	Yes
Automation	Yes
Plugin settings	Yes
Routing	Yes
Audio media	No
MIDI source files	No

Session Versus Media

A common misunderstanding is that recordings are stored inside the project file.

They are not.

The project stores references to media files.

This distinction is critical for:

Backups
Portability
Archiving

Tracks

Tracks organize media on the timeline.

Every track belongs to one of two major categories:

Audio Track

Contains audio clips.

Examples:

Vocals
Guitar
Dialogue

MIDI Track

Contains MIDI events.

Examples:

Piano
Strings
Drum programming

Track Responsibilities

A track manages:

Recording
Playback
Plugin chains
Automation
Routing

Tracks do not contain media directly.

They contain clip references.

Clips

Clips are timeline objects representing content.

Examples:

A vocal take
A guitar recording
A MIDI phrase
A drum loop

Audio Clips

Audio clips reference audio files.

The same audio file can appear in multiple clips.

One recording may therefore be reused many times without duplication.

MIDI Clips

MIDI clips contain event information such as:

Notes
Velocities
Controllers
Program changes

Clip Independence

Clips possess their own:

Start position
End position
Gain
Fade settings
Loop settings

This allows extensive non-destructive editing.

Busses

A bus is a signal collection point.

Tracks send signals into busses.

Busses process and forward signals.

Typical Bus Types

Input Bus

Receives incoming signals.

Output Bus

Delivers signals outward.

Auxiliary Bus

Hosts shared effects.

Examples:

Reverb
Delay

Group Bus

Processes collections of tracks.

Examples:

Drum bus
Vocal bus

Master Bus

Final destination before export or monitoring.

Plugins

Plugins modify or generate signals.

Two major categories exist.

Audio Effects

Examples:

EQ
Compression
Reverb
Delay

Instruments

Examples:

Synthesizers
Samplers
Drum machines

Connections

Connections define signal pathways.

Examples:

Audio:

Input → Track

Track → Bus

Bus → Output

MIDI:

Keyboard → Track

Track → Synth

Synth → Audio Bus

Without connections, signals cannot move.

Automation

Automation records parameter changes across time.

Examples:

Volume changes
Pan changes
Filter sweeps
Effect adjustments

Automation is attached to timeline positions.

Relationship Between Objects

A typical audio path looks like:

Audio File

↓

Clip

↓

Track

↓

Plugins

↓

Bus

↓

Master

↓

Export

A typical MIDI path looks like:

MIDI Clip

↓

MIDI Track

↓

Instrument Plugin

↓

Audio Output

↓

Bus

↓

Master

↓

Export

Non-Destructive Editing

Non-destructive editing is central to Qtractor.

The original source remains unchanged.

Edits are stored as instructions.

Examples:

Trim

Original file:

10 minutes

Visible clip:

15 seconds

Only the visible region is referenced.

Split

One recording becomes:

Clip A
Clip B

No new recording is created.

Fade

Fade information is stored separately.

Audio samples remain untouched.

Why This Matters

Non-destructive workflows provide:

Reversibility
Safety
Faster experimentation
Reduced disk usage

Professional production depends heavily upon these advantages.

Chapter 3 — Signal Flow Fundamentals

Quick Start

Signal flow explains how information moves through a session.

Understanding signal flow eliminates many common production mistakes.

Every operation follows a path.

If the path is understood, behavior becomes predictable.

Audio Signal Flow

The simplest audio path is:

Input

↓

Track

↓

Plugins

↓

Bus

↓

Master

↓

Output

Each stage performs a specific function.

Stage 1 — Audio Input

Audio originates from:

Microphones
Interfaces
External devices
Other applications

Signals enter through assigned inputs.

Stage 2 — Audio Track

The track receives audio.

Track-level controls include:

Record arm
Mute
Solo
Pan
Volume

The track acts as a processing container.

Stage 3 — Plugin Chain

Plugins process audio sequentially.

Example:

↓

Compressor

↓

Saturation

↓

Limiter

Changing plugin order changes results.

Stage 4 — Bus Routing

Tracks typically route into a bus.

Examples:

Drum Bus
Guitar Bus
Vocal Bus

Multiple tracks may share one bus.

Stage 5 — Master Bus

The master bus combines all final signals.

Typical master processing:

EQ
Compression
Limiting

Stage 6 — Output

The final signal reaches:

Speakers
Headphones
Export renderer

MIDI Signal Flow

MIDI differs fundamentally from audio.

MIDI contains instructions.

It does not contain sound.

A typical MIDI path:

Controller

↓

MIDI Track

↓

Instrument

↓

Audio Output

↓

Bus

↓

Master

MIDI Events

Common MIDI events include:

Note On
Note Off
Velocity
Controller Changes
Program Changes
Pitch Bend

These events instruct instruments what to do.

Instrument Conversion

An instrument converts MIDI instructions into audio.

Example:

MIDI note:

↓

Synthesizer

↓

Audio waveform

Without an instrument, MIDI remains silent.

Processing Order

Order matters.

A signal is processed sequentially.

Example:

Track Input

↓

Plugin 1

↓

Plugin 2

↓

Plugin 3

↓

Bus

If Plugin 1 compresses before EQ, results differ from EQ before compression.

Monitoring Path

Monitoring allows listening during production.

Typical monitoring path:

Input

↓

Track

↓

Plugins

↓

Master

↓

Speakers

Monitoring may occur:

Before recording
During recording
During playback

Recording Path

Recording captures source material.

Typical path:

Input

↓

Track

↓

Recorded Media

↓

Session Storage

Recorded media becomes available as clips.

Playback Path

Playback follows:

Clip

↓

Track

↓

Plugins

↓

Bus

↓

Master

↓

Output

Export Path

Export follows:

Clip

↓

Track

↓

Plugins

↓

Bus

↓

Master

↓

Renderer

↓

Audio File

The renderer performs playback without real-time listening requirements.

Gain Staging Fundamentals

Every stage has a level.

Excessive levels may create clipping.

Proper gain staging means:

Healthy input levels
Reasonable plugin levels
Controlled bus levels
Clean master output

Good gain staging improves:

Headroom
Dynamics
Mix quality

Understanding Routing Hierarchies

Simple Session:

Track

↓

Master

Moderate Session:

Track

↓

Group Bus

↓

Master

Large Session:

Track

↓

Subgroup

↓

Stem Bus

↓

Master

Hierarchical routing improves organization and mixing efficiency.

Signal Flow Checklist

Whenever audio is missing, verify:

Source exists.
Input is assigned.
Track is active.
Plugins are functioning.
Bus routing is correct.
Master receives signal.
Output destination is active.

Following signal flow systematically solves the majority of session-level audio and MIDI issues.

PART II — USER INTERFACE & DAILY OPERATION

Chapter 4 — Main Window Architecture

(Continued in Volume 2)

Qtractor Usage Bible - Summary

suntong — Tue, 16 Jun 2026 23:11:29 +0000

Qtractor is a lightweight Linux DAW (Digital Audio Workstation) for audio and MIDI recording.

Organization

This bible series is organized in a workflow-oriented reference fasion that progresses from session creation → recording → editing → mixing → export → advanced techniques.

Contents are organized in consistent chapter sizes fasion, so:

Each installment is about 5,000--8,000 words.
Each installment should be self-contained.
Each installment should end at a natural workflow boundary.
No installment should require information from future installments to be useful.

The Two-Layer Writing Strategy

Each chapter would have four layers:

Layer 1 --- Quick Start

2--5 minute read.
"What is this feature?"

Layer 2 --- Everyday Usage

Typical workflows.
"What do most users actually do?"

Layer 3 --- Power User Techniques

Advanced workflows.

"How do experienced users use it?"

Layer 4 --- Internal Mechanics

Architecture and implementation.

"Why does Qtractor behave this way?"

Content planned

VOLUME 1 --- FOUNDATIONS

Part I --- Qtractor Concepts & Workflow Model

1. What Qtractor Is

2. Understanding the Qtractor Project Model

3. Signal Flow Fundamentals

Part II --- User Interface & Daily Operation

4. Main Window Architecture

5. Navigation & Timeline Control

6. Editing Tools & Selection Mechanics

7. Workspace Customization

VOLUME 2 --- SESSION MANAGEMENT

Part III --- Session Management

8. Creating and Organizing Projects

9. Session Files and Data Structures

10. Asset Management

11. Backup, Versioning & Archival

VOLUME 3 --- AUDIO RECORDING

Part IV --- Audio Recording

12. Audio Tracks & Recording Architecture

13. Recording Workflows

14. Recording Support Tools

15. Managing Takes

VOLUME 4 --- AUDIO EDITING

Part V --- Audio Editing

16. Clip Editing Fundamentals

17. Advanced Audio Editing

18. Fades & Crossfades

19. Audio Processing at Clip Level

VOLUME 5 --- MIDI PRODUCTION

Part VI --- MIDI Production

20. MIDI Fundamentals

21. MIDI Input Sources

22. MIDI Recording Techniques

23. Piano Roll Mastery

24. MIDI Transformations

25. Instrument Definitions

VOLUME 6 --- VIRTUAL INSTRUMENTS

Part VII --- Virtual Instruments & Sound Generation

26. Software Instruments

27. Multi-Timbral Workflows

28. Instrument Preset Management

VOLUME 7 --- MIXING & ROUTING

Part VIII --- Busses, Routing & Mixing

29. The Bus System

30. Mixer Architecture

31. Send & Return Techniques

32. Advanced Routing

VOLUME 8 --- PLUGINS & EFFECTS

Part IX --- Plugins & Effects

33. Plugin Formats

34. Plugin Management

35. Effect Processing Techniques

36. Instrument Hosting

37. Plugin Performance & Latency

VOLUME 9 --- AUTOMATION & CONTROL

Part X --- Automation

38. Automation Concepts

39. Automation Lanes

40. Automation Editing

41. Plugin Automation

Part XI --- Control Surfaces

42. MIDI Control

43. OSC Control

VOLUME 10 --- INTEGRATION & SYNC

Part XII --- Connections, Patchbays & External Integration

44. Connections Window

45. Patchbay

46. Synchronization

47. Video Scoring

VOLUME 11 --- ARRANGEMENT & COMPOSITION

Part XIII --- Arrangement & Composition

48. Song Construction Techniques

49. Loop-Based Production

50. Large Project Management

VOLUME 12 --- RENDERING & DELIVERY

Part XIV --- Rendering & Delivery

51. Freeze, Bounce & Render

52. Audio Export

53. MIDI Export

54. Delivery Workflows

VOLUME 13 --- SPECIALIZED WORKFLOWS

Part XV --- Specialized Workflows

55. Hardware Studio Integration

56. Hybrid Analog/Digital Production

57. Live Performance Use

58. Experimental & Generative Techniques

VOLUME 14 --- REFERENCE MANUAL

Part XVI --- Reference

59. Keyboard Shortcut Reference

60. Menu Reference

61. File Format Reference

62. XML Schema Guide

63. Instrument Definition Reference

64. Glossary

65. Workflow Checklists

Qtractor Complete Guide on Installation and Configuration

suntong — Fri, 05 Jun 2026 21:37:03 +0000

Complete First-Time Setup Guide for Qtractor on Ubuntu 26.04

install and prepare the system
verify audio works
configure PipeWire/JACK
configure Qtractor
record audio
record while playing other tracks
export projects
tune latency
troubleshoot problems

Qtractor is a lightweight Linux DAW (Digital Audio Workstation) for audio and MIDI recording, a hard disk recorder and digital audio workstation application for Linux. If you appreciate highly stable, ultra-lightweight, and low-overhead tools, Qtractor is exceptional. Its developer (Rui Nuno Capela) is incredibly active, having just pushed version 1.6.0 33 days ago as of this writing.

It's setup might be challenging. On Ubuntu, most problems come from:

JACK / PipeWire / ALSA conflicts
Permissions
Wrong audio device selection
Monitoring setup
Sample-rate mismatches
USB devices reconnecting
Tracks not armed correctly

This guide walks through a strategic / systematic / stable setup from zero, and covers the common failure cases along the way.

PART 1 QUICK START SETUP

1. Understanding the Linux Audio Stack

Modern Ubuntu audio typically works like this:

Applications
     ↓
PipeWire
     ↓
JACK compatibility layer
     ↓
ALSA drivers
     ↓
Audio hardware

For Qtractor, the recommended setup is:

PipeWire enabled
JACK compatibility enabled
Qtractor using JACK mode through PipeWire

2. Install the Required Packages

Install everything needed:

sudo apt update

sudo apt install \
qtractor \
pipewire \
pipewire-audio \
pipewire-pulse \
pipewire-jack \
wireplumber \
qpwgraph \
alsa-utils \
qjackctl \
ffmpeg

Useful tools:

Tool	Purpose
qtractor	DAW
qjackctl	JACK control panel
qpwgraph	audio routing graph
helvum	simpler routing
pavucontrol	audio device management
alsa-utils	microphone troubleshooting

helvum and pavucontrol are listed as reference but not in the installation list, as many experienced Linux audio users eventually stop opening Helvum entirely and do everything through qpwgraph -- In daily use:

Use qpwgraph as your primary routing tool.
Use Helvum only if you prefer its simpler visual layout or want a quick sanity check of the PipeWire graph.

For pavucontrol, I'm using KUbuntu so I installed pavucontrol-qt instead.

3. Reboot

After installation:

reboot

This ensures all audio services start cleanly.

4. Verify the Audio System Is Running

Check PipeWire:

systemctl --user status pipewire

Check WirePlumber:

systemctl --user status wireplumber

Check Pulse compatibility:

systemctl --user status pipewire-pulse

You should see:

active (running)

5. Verify Audio Devices Exist

Check Playback Devices

aplay -l

Check Recording Devices

arecord -l

Check PipeWire Audio Nodes

wpctl status

You should see sections like:

Audio
    Devices
    Sinks
    Sources

Typical onboard audio may appear as:

Built-in Audio Analog Stereo

6. Verify Sound Playback Works

Test speaker output:

speaker-test -c 2

You should hear alternating left/right sound.

Press:

Ctrl+C

to stop.

7. Verify Microphone Input Works

Open the ALSA mixer:

alsamixer

Press:

F6

Select your sound card.

Verify:

capture channels are enabled
input volume is reasonable
channels are not muted

Muted channels show:

MM

Enabled channels show:

OO

Toggle mute with:

Make sure microphone input works by doing a test recording:

pw-record /tmp/test-rec.wav
pw-play /tmp/test-rec.wav

8. Verify PipeWire Audio Routing

Launch:

qpwgraph &

You should see:

audio devices
playback nodes
capture nodes
PipeWire graph connections

This tool becomes extremely important later.

9. Launch Qtractor Properly

Recommended launch method:

pw-jack qtractor &

This ensures Qtractor uses PipeWire s JACK compatibility layer correctly.

10. Configure Qtractor Audio Settings

Inside Qtractor:
View →  Options →  Audio
Recommended settings:

Setting Value

Driver JACK

Sample Rate 48000

Buffer Size 256 or 512

Channels Stereo

Restart Qtractor after changes.

Setting	Value
Driver	JACK
Sample Rate	48000
Buffer Size	256 or 512
Channels	Stereo

Didn't find the above part. The workaround is to use pw-top to verify what PipeWire is actually using:

Start pw-top

Then look for:

QUANT RATE

Example:

QUANT 1024
RATE 48000

Meaning:

Buffer Size = 1024
Sample Rate = 48000 Hz

11. Verify Qtractor Audio Engine

When Qtractor opens:

Verifying Qtractor Started Correctly

When Qtractor opens successfully, three things should be true:

no engine errors appear
transport controls are active
audio meters function correctly

The last two are important because Qtractor can sometimes open partially working even when the audio engine is not fully operational.

If the engine fails to start, or partially working, see troubleshooting later.

11.1 Verify Transport Controls Are Active

The transport controls are the playback/record controls usually located near the top toolbar.

Typical controls include:

Control	Purpose
Play	start playback
Stop	stop playback
Record	arm global recording
Rewind	move playhead backward
Fast Forward	move playhead forward
Loop	repeat playback region

What Active Means

When the audio engine is working correctly:

buttons respond immediately
Play starts timeline movement
Stop halts playback
Record engages recording mode
time counter advances during playback
playhead moves smoothly across timeline

Visual Indicators of a Working Transport

Timeline Movement

Press:

Play

Expected result:

playhead moves left-to-right
timeline counter advances continuously
transport clock changes in real time

Example:

00:00:01
00:00:02
00:00:03

If the counter stays frozen:

audio engine likely failed
JACK connection may be broken
transport backend may not be running

Play Button State

When playback begins:

Play button usually highlights or changes state
Stop becomes available
CPU/audio indicators may activate

If Play immediately returns to idle:

engine likely stopped internally
invalid routing or backend failure possible

Record Button Behavior

When Record is enabled:

global Record button lights up
armed tracks indicate recording readiness
pressing Play starts actual recording

If Record cannot be enabled:

transport engine may not exist
audio backend failed initialization

What Broken Transport Looks Like

Common symptoms:

Symptom	Likely Cause
Play button does nothing	engine not running
timeline frozen	JACK/PipeWire disconnected
Record button disabled	no active audio engine
playback instantly stops	routing/backend issue
transport buttons greyed out	engine startup failure

Verify JACK Transport Exists

Open:

qpwgraph

You should see Qtractor nodes such as:

qtractor

or:

qtractor-master

If Qtractor does not appear at all:

JACK compatibility failed
Qtractor engine not started

Verify Engine Messages

Inside Qtractor:

View → Messages

A healthy startup usually shows messages similar to:

JACK started
Audio activated
MIDI activated

Didn't see that, but on openning new files, saw:

Session closed.
Session started.
New session: "Untitled1".
MIDI connections change.
Audio connections change.

Problematic examples:

Cannot connect to JACK server

or:

Audio device not available

11.2 Verify Audio Meters Function Correctly

Meters confirm that audio signals are actually flowing.

Even when transport works, meters may reveal:

missing routing
silent inputs
muted tracks
disconnected outputs
inactive monitoring

Types of Meters in Qtractor

You may see:

Meter	Purpose
Track input meter	incoming recording signal
Track playback meter	playback signal
Master meter	final mixed output
MIDI activity indicators	MIDI note activity

Verify Playback Meters

Import or record a short audio clip.

Press:

Play

Expected behavior:

track meters move dynamically
master output meters move
audio is heard from speakers/headphones

What Healthy Meter Movement Looks Like

Meters should:

rise and fall continuously
react to loud/quiet audio
peak near louder sounds
return downward smoothly

Example:

Verify Recording/Input Meters

Arm an audio track.

Speak into microphone.

Expected behavior:

armed track input meter reacts immediately
louder speech produces higher levels
silence returns meter near zero

If Input Meter Moves But Nothing Records

Possible causes:

global Record not enabled
playback never started
recording path invalid
disk write permissions issue

If Playback Meter Moves But No Sound Is Heard

Possible causes:

output routing broken
wrong playback device
muted system output
disconnected PipeWire graph

Check:

qpwgraph

Verify:

Qtractor Output

System Playback

If No Meters Move At All

Most likely causes:

Cause	Description
engine failed	JACK/PipeWire inactive
no routing	disconnected graph
muted input	ALSA/PipeWire mute
wrong device	incorrect source selected
disconnected hardware	USB/audio issue

Proper Recording Levels

Avoid recording too quietly or too loudly.

Recommended Recording Peaks

Typical safe peak range:

-18 dB to -6 dB

Avoid constant clipping near:

0 dB

Clipping Indicators

Red meter peaks indicate clipping/distortion.

If clipping occurs:

reduce microphone gain
reduce interface input gain
lower ALSA capture level

Verifying Meter Activity Outside Qtractor

If uncertain whether Qtractor or the system is failing:

Run:

pw-top

Speak into microphone.

You should see activity changes for:

input nodes
Qtractor nodes
output nodes

This confirms PipeWire signal flow exists.

Final Healthy-State Checklist

A fully working Qtractor session should have ALL of these:

Check	Expected Result
Play button works	yes
timeline moves	yes
Record button arms	yes
input meters react	yes
playback meters react	yes
master meters react	yes
sound audible	yes
qpwgraph shows routes	yes
wpctl status shows devices	yes

If all are true, the audio engine, routing, recording, and playback systems are functioning correctly.

(Image not reflecting the actual Qtractor GUI)

PART 2 FIRST RECORDING

12. Create a New Session

Inside Qtractor:

File   New

Create a dedicated project folder.

Recommended structure:

Projects/
     Song/
          audio/
          exports/
          backups/

13. Add an Audio Track

Track   Add Track

Choose:

Setting	Value
Type	Audio
Channels	Mono or Stereo
Name	Vocals

Mono is usually correct for microphones.

14. Arm the Track for Recording

Click the track s red record-arm button.

The track is now ready to record.

15. Enable Main Recording

Press the global Record button in the toolbar.

16. Start Recording

Press:

Play
or Spacebar

Recording begins.

Waveforms should appear.

17. Verify Recorded Audio Works

Stop recording.

Rewind.

Press Play.

Verify:

waveform exists
audio is audible
meters move during playback

If not, see troubleshooting later.

PART 3 UNDERSTANDING ROUTING

18. Linux Audio Routing Basics

Signals travel like this:

Microphone

PipeWire Input Node

Qtractor Input

Track

Master Output

Speakers

If any connection is missing:

no sound
silent recording
missing monitoring
playback problems

19. Verify Input Connections

Open:

qpwgraph

Verify:

Audio Input Device

Qtractor Capture Input

Example:

alsa_input

qtractor:input_1

20. Verify Playback Connections

Verify:

Qtractor Master Output

System Output

Example:

qtractor:output_1

alsa_output

PART 4 MONITORING

21. Monitoring While Recording

Monitoring means hearing yourself while recording.

Two methods exist.

Software Monitoring

Handled by Qtractor.

Pros:

hear effects/plugins live

Cons:

more latency

Enable monitoring in track settings.

Hardware Monitoring

Handled directly by audio interface hardware.

Pros:

near-zero latency

Cons:

no software effects while recording

22. Verify Monitoring Works

Arm track.

Speak into microphone.

Verify:

Qtractor meters move
audio is heard in headphones/speakers

If meters move but nothing is heard:

monitoring disabled
routing incorrect
output muted

PART 5 MULTITRACK RECORDING

23. Recording While Playing Existing Tracks

Typical workflow:

existing music plays
new track records simultaneously

24. Procedure

Existing Tracks

Leave unarmed.

New Track

Arm only the new recording track.

Start Recording

Press:

Record + Play

Now:

old tracks play normally
new audio records simultaneously

25. Verify Synchronization

After recording:

rewind
play all tracks together

Verify timing alignment.

PART 6 IMPORTING AND EXPORTING

26. Import Audio Files

Drag and Drop

Drag WAV/FLAC into timeline.

Manual Import

Right-click Track   Import Audio

27. Export Final Audio

File   Export   Audio

Recommended settings:

Setting	Value
Format	WAV
Sample Rate	48000
Bit Depth	24-bit

28. Convert WAV to MP3

ffmpeg -i mix.wav mix.mp3

PART 7 MIDI RECORDING

29. Verify MIDI Devices

aconnect -i

You should see connected MIDI devices.

30. Add MIDI Track

Track   Add Track   MIDI

31. Verify MIDI Routing

In:

qpwgraph

Verify:

MIDI Keyboard

Qtractor MIDI Input

PART 8 LATENCY AND PERFORMANCE

32. Buffer Size Recommendations

Buffer	Use
128	low-latency recording
256	balanced
512	stable mixing
1024	weak hardware

33. Verify Current Audio Performance

Run:

pw-top

Important fields:

Field	Meaning
RATE	sample rate
QUANT	buffer
CPU	processing load
ERR	xruns/errors

34. Avoid XRUNS and Crackling

If audio crackles:

increase buffer size
close heavy applications
avoid Bluetooth audio
use wired headphones
avoid USB hubs

PART 9 TROUBLESHOOTING

Organized from most common to least common.

35. Qtractor Audio Engine Will Not Start

Symptoms

engine start error
transport disabled
playback unavailable

Solution 1 Launch with PipeWire JACK

pw-jack qtractor

Solution 2 Kill Old JACK Servers

killall jackd

Restart PipeWire:

systemctl --user restart pipewire
systemctl --user restart wireplumber

Solution 3 Verify JACK Driver Setting

Inside Qtractor:

View   Options   Audio

Set:

Driver = JACK

36. No Sound During Playback

Verify Output Routing

Open:

qpwgraph

Verify:

Qtractor Outputs

System Playback

Verify Output Device

Open:

pavucontrol

Verify correct output device selected.

Verify System Audio

Run:

speaker-test -c 2

37. Recording Is Silent

Verify Input Routing

In:

qpwgraph

Verify:

Input Device

Qtractor Capture

Verify Input Gain

Run:

alsamixer

Increase capture gain.

Verify Input Device

Open:

pavucontrol

Check:

Input Devices

Verify Signal Activity

Run:

pw-top

Speak into microphone and watch activity.

38. Monitoring Does Not Work

Verify Monitoring Enabled

Enable monitoring on the track.

Verify Output Routing

Check in:

qpwgraph

Avoid Double Monitoring

Disable either:

hardware monitoring
software monitoring

not both simultaneously.

39. Built-in Audio Analog Stereo Missing

Verify ALSA Detects Hardware

aplay -l

and:

arecord -l

Restart PipeWire Stack

systemctl --user restart pipewire
systemctl --user restart wireplumber
systemctl --user restart pipewire-pulse

Then verify:

wpctl status

Verify Audio Profiles

Open:

pavucontrol

Go to:

Configuration

Set profile to:

Analog Stereo Duplex

Reload ALSA

sudo alsa force-reload

Restart PipeWire afterward.

Verify Kernel Detection

dmesg | grep -i audio

and:

lspci | grep -i audio

40. Audio Device Disappears Randomly

Disable Audio Power Saving

Create:

sudo nano /etc/modprobe.d/disable-audio-powersave.conf

Add:

options snd_hda_intel power_save=0
options snd_usb_audio power_save=0

Reboot.

Avoid USB Hubs

Connect interfaces directly to motherboard ports.

Check Kernel Logs

dmesg | tail -50

Look for:

USB resets
disconnects
power faults

41. Crackling, Pops, Distortion

Increase Buffer Size

Inside Qtractor:

View   Options   Audio

Try:

or:

Verify CPU Load

pw-top

42. HDMI Audio Takes Over

Open:

pavucontrol

Select correct analog output manually.

43. Broken Audio Graph Connections

Restart WirePlumber:

systemctl --user restart wireplumber

Reopen:

qpwgraph

Reconnect missing nodes.

44. Complete Diagnostic Sequence

When audio problems happen, check in this order:

wpctl status

qpwgraph

pw-top

alsamixer

pavucontrol

Those tools diagnose most Linux audio problems quickly.

Qtractor Complete Guide on Installation and Configuration

suntong — Wed, 03 Jun 2026 21:39:31 +0000

Complete First-Time Setup Guide for Qtractor on Ubuntu 26.04

install and prepare the system
verify audio works
configure PipeWire/JACK
configure Qtractor
record audio
record while playing other tracks
export projects
tune latency
troubleshoot problems

It's setup might be challenging. On Ubuntu, most problems come from:

JACK / PipeWire / ALSA conflicts
Permissions
Wrong audio device selection
Monitoring setup
Sample-rate mismatches
USB devices reconnecting
Tracks not armed correctly

This guide walks through a strategic / systematic / stable setup from zero, and covers the common failure cases along the way.

PART 1 QUICK START SETUP

1. Understanding the Linux Audio Stack

Modern Ubuntu audio typically works like this:

Applications
     ↓
PipeWire
     ↓
JACK compatibility layer
     ↓
ALSA drivers
     ↓
Audio hardware

For Qtractor, the recommended setup is:

PipeWire enabled
JACK compatibility enabled
Qtractor using JACK mode through PipeWire

2. Install the Required Packages

Install everything needed:

sudo apt update

sudo apt install \
qtractor \
pipewire \
pipewire-audio \
pipewire-pulse \
pipewire-jack \
wireplumber \
qpwgraph \
alsa-utils \
qjackctl \
ffmpeg

Useful tools:

Tool	Purpose
qtractor	DAW
qjackctl	JACK control panel
qpwgraph	audio routing graph
helvum	simpler routing
pavucontrol	audio device management
alsa-utils	microphone troubleshooting

Use qpwgraph as your primary routing tool.
Use Helvum only if you prefer its simpler visual layout or want a quick sanity check of the PipeWire graph.

For pavucontrol, I'm using KUbuntu so I installed pavucontrol-qt instead.

3. Reboot

After installation:

reboot

This ensures all audio services start cleanly.

4. Verify the Audio System Is Running

Check PipeWire:

systemctl --user status pipewire

Check WirePlumber:

systemctl --user status wireplumber

Check Pulse compatibility:

systemctl --user status pipewire-pulse

You should see:

active (running)

5. Verify Audio Devices Exist

Check Playback Devices

aplay -l

Check Recording Devices

arecord -l

Check PipeWire Audio Nodes

wpctl status

You should see sections like:

Audio
    Devices
    Sinks
    Sources

Typical onboard audio may appear as:

Built-in Audio Analog Stereo

6. Verify Sound Playback Works

Test speaker output:

speaker-test -c 2

You should hear alternating left/right sound.

Press:

Ctrl+C

to stop.

7. Verify Microphone Input Works

Open the ALSA mixer:

alsamixer

Press:

F6

Select your sound card.

Verify:

capture channels are enabled
input volume is reasonable
channels are not muted

Muted channels show:

MM

Enabled channels show:

OO

Toggle mute with:

Make sure microphone input works by doing a test recording:

pw-record /tmp/test-rec.wav
pw-play /tmp/test-rec.wav

8. Verify PipeWire Audio Routing

Launch:

qpwgraph &

You should see:

audio devices
playback nodes
capture nodes
PipeWire graph connections

This tool becomes extremely important later.

9. Launch Qtractor Properly

Recommended launch method:

pw-jack qtractor &

This ensures Qtractor uses PipeWire s JACK compatibility layer correctly.

10. Configure Qtractor Audio Settings

Inside Qtractor:
View →  Options →  Audio
Recommended settings:

Setting Value

Driver JACK

Sample Rate 48000

Buffer Size 256 or 512

Channels Stereo

Restart Qtractor after changes.

Setting	Value
Driver	JACK
Sample Rate	48000
Buffer Size	256 or 512
Channels	Stereo

Didn't find the above part. The workaround is to use pw-top to verify what PipeWire is actually using:

Start pw-top

Then look for:

QUANT RATE

Example:

QUANT 1024
RATE 48000

Meaning:

Buffer Size = 1024
Sample Rate = 48000 Hz

11. Verify Qtractor Audio Engine

When Qtractor opens:

Verifying Qtractor Started Correctly

When Qtractor opens successfully, three things should be true:

no engine errors appear
transport controls are active
audio meters function correctly

The last two are important because Qtractor can sometimes open partially working even when the audio engine is not fully operational.

If the engine fails to start, or partially working, see troubleshooting later.

11.1 Verify Transport Controls Are Active

The transport controls are the playback/record controls usually located near the top toolbar.

Typical controls include:

Control	Purpose
Play	start playback
Stop	stop playback
Record	arm global recording
Rewind	move playhead backward
Fast Forward	move playhead forward
Loop	repeat playback region

What Active Means

When the audio engine is working correctly:

buttons respond immediately
Play starts timeline movement
Stop halts playback
Record engages recording mode
time counter advances during playback
playhead moves smoothly across timeline

Visual Indicators of a Working Transport

Timeline Movement

Press:

Play

Expected result:

playhead moves left-to-right
timeline counter advances continuously
transport clock changes in real time

Example:

00:00:01
00:00:02
00:00:03

If the counter stays frozen:

audio engine likely failed
JACK connection may be broken
transport backend may not be running

Play Button State

When playback begins:

Play button usually highlights or changes state
Stop becomes available
CPU/audio indicators may activate

If Play immediately returns to idle:

engine likely stopped internally
invalid routing or backend failure possible

Record Button Behavior

When Record is enabled:

global Record button lights up
armed tracks indicate recording readiness
pressing Play starts actual recording

If Record cannot be enabled:

transport engine may not exist
audio backend failed initialization

What Broken Transport Looks Like

Common symptoms:

Symptom	Likely Cause
Play button does nothing	engine not running
timeline frozen	JACK/PipeWire disconnected
Record button disabled	no active audio engine
playback instantly stops	routing/backend issue
transport buttons greyed out	engine startup failure

Verify JACK Transport Exists

Open:

qpwgraph

You should see Qtractor nodes such as:

qtractor

or:

qtractor-master

If Qtractor does not appear at all:

JACK compatibility failed
Qtractor engine not started

Verify Engine Messages

Inside Qtractor:

View → Messages

A healthy startup usually shows messages similar to:

JACK started
Audio activated
MIDI activated

Didn't see that, but on openning new files, saw:

Session closed.
Session started.
New session: "Untitled1".
MIDI connections change.
Audio connections change.

Problematic examples:

Cannot connect to JACK server

or:

Audio device not available

11.2 Verify Audio Meters Function Correctly

Meters confirm that audio signals are actually flowing.

Even when transport works, meters may reveal:

missing routing
silent inputs
muted tracks
disconnected outputs
inactive monitoring

Types of Meters in Qtractor

You may see:

Meter	Purpose
Track input meter	incoming recording signal
Track playback meter	playback signal
Master meter	final mixed output
MIDI activity indicators	MIDI note activity

Verify Playback Meters

Import or record a short audio clip.

Press:

Play

Expected behavior:

track meters move dynamically
master output meters move
audio is heard from speakers/headphones

What Healthy Meter Movement Looks Like

Meters should:

rise and fall continuously
react to loud/quiet audio
peak near louder sounds
return downward smoothly

Example:

Verify Recording/Input Meters

Arm an audio track.

Speak into microphone.

Expected behavior:

armed track input meter reacts immediately
louder speech produces higher levels
silence returns meter near zero

If Input Meter Moves But Nothing Records

Possible causes:

global Record not enabled
playback never started
recording path invalid
disk write permissions issue

If Playback Meter Moves But No Sound Is Heard

Possible causes:

output routing broken
wrong playback device
muted system output
disconnected PipeWire graph

Check:

qpwgraph

Verify:

Qtractor Output

System Playback

If No Meters Move At All

Most likely causes:

Cause	Description
engine failed	JACK/PipeWire inactive
no routing	disconnected graph
muted input	ALSA/PipeWire mute
wrong device	incorrect source selected
disconnected hardware	USB/audio issue

Proper Recording Levels

Avoid recording too quietly or too loudly.

Recommended Recording Peaks

Typical safe peak range:

-18 dB to -6 dB

Avoid constant clipping near:

0 dB

Clipping Indicators

Red meter peaks indicate clipping/distortion.

If clipping occurs:

reduce microphone gain
reduce interface input gain
lower ALSA capture level

Verifying Meter Activity Outside Qtractor

If uncertain whether Qtractor or the system is failing:

Run:

pw-top

Speak into microphone.

You should see activity changes for:

input nodes
Qtractor nodes
output nodes

This confirms PipeWire signal flow exists.

Final Healthy-State Checklist

A fully working Qtractor session should have ALL of these:

Check	Expected Result
Play button works	yes
timeline moves	yes
Record button arms	yes
input meters react	yes
playback meters react	yes
master meters react	yes
sound audible	yes
qpwgraph shows routes	yes
wpctl status shows devices	yes

If all are true, the audio engine, routing, recording, and playback systems are functioning correctly.

(Image not reflecting the actual Qtractor GUI)

PART 2 FIRST RECORDING

12. Create a New Session

Inside Qtractor:

File   New

Create a dedicated project folder.

Recommended structure:

Projects/
     Song/
          audio/
          exports/
          backups/

13. Add an Audio Track

Track   Add Track

Choose:

Setting	Value
Type	Audio
Channels	Mono or Stereo
Name	Vocals

Mono is usually correct for microphones.

14. Arm the Track for Recording

Click the track s red record-arm button.

The track is now ready to record.

15. Enable Main Recording

Press the global Record button in the toolbar.

16. Start Recording

Press:

Play
or Spacebar

Recording begins.

Waveforms should appear.

17. Verify Recorded Audio Works

Stop recording.

Rewind.

Press Play.

Verify:

waveform exists
audio is audible
meters move during playback

If not, see troubleshooting later.

PART 3 UNDERSTANDING ROUTING

18. Linux Audio Routing Basics

Signals travel like this:

Microphone

PipeWire Input Node

Qtractor Input

Track

Master Output

Speakers

If any connection is missing:

no sound
silent recording
missing monitoring
playback problems

19. Verify Input Connections

Open:

qpwgraph

Verify:

Audio Input Device

Qtractor Capture Input

Example:

alsa_input

qtractor:input_1

20. Verify Playback Connections

Verify:

Qtractor Master Output

System Output

Example:

qtractor:output_1

alsa_output

PART 4 MONITORING

21. Monitoring While Recording

Monitoring means hearing yourself while recording.

Two methods exist.

Software Monitoring

Handled by Qtractor.

Pros:

hear effects/plugins live

Cons:

more latency

Enable monitoring in track settings.

Hardware Monitoring

Handled directly by audio interface hardware.

Pros:

near-zero latency

Cons:

no software effects while recording

22. Verify Monitoring Works

Arm track.

Speak into microphone.

Verify:

Qtractor meters move
audio is heard in headphones/speakers

If meters move but nothing is heard:

monitoring disabled
routing incorrect
output muted

PART 5 MULTITRACK RECORDING

23. Recording While Playing Existing Tracks

Typical workflow:

existing music plays
new track records simultaneously

24. Procedure

Existing Tracks

Leave unarmed.

New Track

Arm only the new recording track.

Start Recording

Press:

Record + Play

Now:

old tracks play normally
new audio records simultaneously

25. Verify Synchronization

After recording:

rewind
play all tracks together

Verify timing alignment.

PART 6 IMPORTING AND EXPORTING

26. Import Audio Files

Drag and Drop

Drag WAV/FLAC into timeline.

Manual Import

Right-click Track   Import Audio

27. Export Final Audio

File   Export   Audio

Recommended settings:

Setting	Value
Format	WAV
Sample Rate	48000
Bit Depth	24-bit

28. Convert WAV to MP3

ffmpeg -i mix.wav mix.mp3

PART 7 MIDI RECORDING

29. Verify MIDI Devices

aconnect -i

You should see connected MIDI devices.

30. Add MIDI Track

Track   Add Track   MIDI

31. Verify MIDI Routing

In:

qpwgraph

Verify:

MIDI Keyboard

Qtractor MIDI Input

PART 8 LATENCY AND PERFORMANCE

32. Buffer Size Recommendations

Buffer	Use
128	low-latency recording
256	balanced
512	stable mixing
1024	weak hardware

33. Verify Current Audio Performance

Run:

pw-top

Important fields:

Field	Meaning
RATE	sample rate
QUANT	buffer
CPU	processing load
ERR	xruns/errors

34. Avoid XRUNS and Crackling

If audio crackles:

increase buffer size
close heavy applications
avoid Bluetooth audio
use wired headphones
avoid USB hubs

PART 9 TROUBLESHOOTING

Organized from most common to least common.

35. Qtractor Audio Engine Will Not Start

Symptoms

engine start error
transport disabled
playback unavailable

Solution 1 Launch with PipeWire JACK

pw-jack qtractor

Solution 2 Kill Old JACK Servers

killall jackd

Restart PipeWire:

systemctl --user restart pipewire
systemctl --user restart wireplumber

Solution 3 Verify JACK Driver Setting

Inside Qtractor:

View   Options   Audio

Set:

Driver = JACK

36. No Sound During Playback

Verify Output Routing

Open:

qpwgraph

Verify:

Qtractor Outputs

System Playback

Verify Output Device

Open:

pavucontrol

Verify correct output device selected.

Verify System Audio

Run:

speaker-test -c 2

37. Recording Is Silent

Verify Input Routing

In:

qpwgraph

Verify:

Input Device

Qtractor Capture

Verify Input Gain

Run:

alsamixer

Increase capture gain.

Verify Input Device

Open:

pavucontrol

Check:

Input Devices

Verify Signal Activity

Run:

pw-top

Speak into microphone and watch activity.

38. Monitoring Does Not Work

Verify Monitoring Enabled

Enable monitoring on the track.

Verify Output Routing

Check in:

qpwgraph

Avoid Double Monitoring

Disable either:

hardware monitoring
software monitoring

not both simultaneously.

39. Built-in Audio Analog Stereo Missing

Verify ALSA Detects Hardware

aplay -l

and:

arecord -l

Restart PipeWire Stack

systemctl --user restart pipewire
systemctl --user restart wireplumber
systemctl --user restart pipewire-pulse

Then verify:

wpctl status

Verify Audio Profiles

Open:

pavucontrol

Go to:

Configuration

Set profile to:

Analog Stereo Duplex

Reload ALSA

sudo alsa force-reload

Restart PipeWire afterward.

Verify Kernel Detection

dmesg | grep -i audio

and:

lspci | grep -i audio

40. Audio Device Disappears Randomly

Disable Audio Power Saving

Create:

sudo nano /etc/modprobe.d/disable-audio-powersave.conf

Add:

options snd_hda_intel power_save=0
options snd_usb_audio power_save=0

Reboot.

Avoid USB Hubs

Connect interfaces directly to motherboard ports.

Check Kernel Logs

dmesg | tail -50

Look for:

USB resets
disconnects
power faults

41. Crackling, Pops, Distortion

Increase Buffer Size

Inside Qtractor:

View   Options   Audio

Try:

or:

Verify CPU Load

pw-top

42. HDMI Audio Takes Over

Open:

pavucontrol

Select correct analog output manually.

43. Broken Audio Graph Connections

Restart WirePlumber:

systemctl --user restart wireplumber

Reopen:

qpwgraph

Reconnect missing nodes.

44. Complete Diagnostic Sequence

When audio problems happen, check in this order:

wpctl status

qpwgraph

pw-top

alsamixer

pavucontrol

Those tools diagnose most Linux audio problems quickly.

Google Docs no longer take free spaces in Google Drive

suntong — Sun, 06 Nov 2022 01:27:44 +0000

Everyone believes that their Google Docs sizes are not counted into the total 15G free spaces allocated, but it is no longer true!!

I found out today and it is quite a surprise to me and I have to triple-validate it before posting it here.

Google never said anything about it and it seems that most people aren't unaware of such new situation. Take this article for example, which is only published this year at MAY 25, 2022, still believe otherwise:

These Things Do Not Count

Google does not count any word documents you create in Google Docs, any spreadsheets from Google Sheets, any presentation slideshows from Google Slides (thankfully), any forms or surveys from Google Forms, or any information for Google Sites.

Moreover, as of Saturday, November 05, 2022, this is what wikipedia says about Google Drive:

Google gives every user 15 GB (1 GB = 1 billion bytes) of free storage through Google One. Google Docs, Google Sheets and Google Slides files do not count towards the storage limit.^[35]

YET, they do now!

Be aware!

st - the suckless simple terminal, v0.9

suntong — Sun, 16 Oct 2022 19:43:38 +0000

TL;DR

This Debian package does provide a scrollback buffer, it also supports color emoji, and it shows Chinese beautifully:

Why bother

For decades, I settled with urxvt to display Chinese, despite all its quirks, like surprising hot-keys and not supporting color emoji.

However, it is its "helpful" anti-aliasing font effect under WSL that become the last straw that broke the camel's back:

As I was not able to get rid of the above anti-aliasing effect under WSL.

Why not Alacritty

I agree with the comment from reddit that:

It's Ok to use Alacritty,

if you really want something a bit more bloated, and don't mind using rust software.

Alacritty
Like GNOME, it may look nice, but it consumes way too much RAM for a barebone terminal emulator IMO.

$ ps -eo comm,rss,pcpu | grep -E 'xterm|alacritty'

xterm 13052 0.0
alacritty 38884 0.1

Depending on your distribution, the packaged alacritty may be fatter than others. Here on Fedora (rawhide) is the new GNOME 42 terminal...

ps -eo comm,rss,pcpu | grep -E 'terminal|kitty|st'
kitty           83668  0.5
alacritty       69668  1.3
gnome-terminal- 61260  6.4
st              10172  0.3 (unpatched)

I don't mind it is 4+ the size of st as long as I can get a precompiled Debian/Ubuntu package (as I really don't want to compile any packages myself). However, I gave up alacritty for the exact reason posted under here:

Something to note when using a gpu based terminal. Having the terminal emulator open will make the gpu ramp up a few power states. My 1080ti goes into power state 3, which results in an extra ~30 watts at the wall over using st, urxvt, etc.
Don't get me wrong, alacritty is amazing, but it's not worth the extra power draw for me.

I.e., despite how amazing it is, I'm not willing to let my laptop run hot all the time and reduce its battery time just for some fancy visual effects.

Why not sticking to the official precompiled Debian/Ubuntu package?

Despite how I dislike compiling packages myself, I cannot bear with the official precompiled Debian/Ubuntu package because it does not provide a scrollback buffer, and it crashes when displaying color emojis.

My precompiled Ubuntu package

Because I really don't want to compile any packages myself, and because the only way to get st is to compile it yourself, I'm providing this precompiled Ubuntu package in hoping that it'll help someone like me. It is built right from source git repo, thus it now supports color emoji, and it'll always give you the latest version. Besides, I added the patch so it does provide a scrollback buffer.

Here is how to get it installed under Debian 11 bullseye (Ubuntu would be similar but simpler):

Check out ppa:suntong001/ppa at https://launchpad.net/~suntong001/+archive/ubuntu/ppa:

This PPA can be added to your Debian 11 system manually by copying the lines below and adding them to your system's software sources.

deb https://ppa.launchpadcontent.net/suntong001/ppa/ubuntu focal main 
deb-src https://ppa.launchpadcontent.net/suntong001/ppa/ubuntu focal main

Then, after apt update, do:

apt-cache policy stterm libxft2
apt install stterm libxft2

Recheck:

$ apt-cache policy stterm libxft2
stterm:
  Installed: 0.9.1~20221004~ubuntu20.04.1
  Candidate: 0.9.1~20221004~ubuntu20.04.1
  Version table:
 *** 0.9.1~20221004~ubuntu20.04.1 500
        500 http://ppa.launchpad.net/suntong001/ppa/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status
     0.8.5-1 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
     0.8.4-1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
     0.8.2-1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages

libxft2:
  Installed: 2.3.6-1
  Candidate: 2.3.6-1
  Version table:
 *** 2.3.6-1 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status
     2.3.6-1~202209251622~ubuntu20.04.1 500
        500 http://ppa.launchpad.net/suntong001/ppa/ubuntu focal/main amd64 Packages
     2.3.2-2 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        500 http://deb.debian.org/debian buster/main amd64 Packages

That's it. Enjoy 😃.

Transforming json data with easygen

suntong — Fri, 31 Dec 2021 04:00:35 +0000

Filtering

Take a look at the vast amount of data a github API may return, e.g.: https://api.github.com/search/repositories?q=go.

If there is only few key data that we want, then the first thing to do is to filter out the unwanted. Can easygen do that? Yes, of course. Given the power of Go template engine, everything is possible. However, such filtering is imperative programming if done in easygen, especially when doing vertically filtering (skipping unwanted records). So it is better to use the declarative approach, using tools like jp or jq instead. Since that is outside of the scope of this article, we'll skip it and move on to the next section.

Presenting

Take a look at the end result first, at https://github.com/go-sqlparser/current/wiki/List:-Currently-Collected-Projects:

Here is what happening behind the scene -- the mark down source code that renders above:

Note that

the project name keyword has been repeated five times in the mark down source code.
there is a TOC index that links directly to the detailed content. I.e., each project is repeated twice, first listed briefly in the TOC/index section, then full details in the following section.
the PrimaryLanguage is therefore need to be repeated in two sections as well.

Such repetitive tasks are best leave to tools to automate it, and easygen is such code/text auto generating tools. The mark down code generation template is as simple as this:

$ cat repos.tmpl 
## Currently Collected Projects

### List
{{range .Data.RepositoryOwner.Repositories.Edges}}
- [{{.Node.Name}} ({{.Node.PrimaryLanguage.PrimaryLanguage}})](#{{.Node.Name}}){{end}}

### Details
{{range .Data.RepositoryOwner.Repositories.Edges}}
<a name="{{.Node.Name}}"/>**{{.Node.Name}}** ({{.Node.PrimaryLanguage.PrimaryLanguage}})  
{{.Node.Url}}  
{{.Node.Description}}
{{end}}

To put them together

So in order to come up with the above end result, I need to

download json data via API
filter the json data with the jp
then present the json data in human friendly mark down format with the new easygen that can read from stdin.
in the human friendly form, if I need to convert the long number of project size from bytes to the size in KB or MB, and I can make use of easygen's built in calculation in Go template supports.
there are lots of other transformation support functions already builtin inside easygen, check out the full list with sample usage and results here.

UPDATE:

project size added to list details:

and here is the updated code generation template:

$ cat repos.tmpl 
## Currently Collected Projects

### List
{{range .Data.RepositoryOwner.Repositories.Edges}}
- [{{.Node.Name}} ({{.Node.PrimaryLanguage.PrimaryLanguage}})](#{{.Node.Name}}){{end}}

### Details
{{range .Data.RepositoryOwner.Repositories.Edges}}{{$mb := sprintf "%.2f" (divide .Node.Size 1024)}}
<a name="{{.Node.Name}}"/>**{{.Node.Name}}** ({{.Node.PrimaryLanguage.PrimaryLanguage}}, {{.Node.Size}}KB/{{$mb}}MB)  
{{.Node.Url}}  
{{ coalesce .Node.Description "No description" }}
{{end}}

Credit

The cover image is obtained from imd.org.

What is the "XSLT" equivalent for JSON? Here is the new answer

suntong — Thu, 30 Dec 2021 04:33:55 +0000

Prefix

What is the "XSLT" equivalent for JSON?

This is the question that people had been asking more than 10 years ago. By then the xslt is still the number one answer.

It's high time to take a look at the new kids in town now.

What is "XSLT"?

XSLT stands for XSL Transformation. It is used to transform XML documents into into various other types of document (like transforming XML into HTML).

It's most important purpose is transform data, from XML form into a format more presentable to human beings.

XSL is to XML is similar as CSS is to HTML. XSLT can be viewed as the rendering engine.

What are the new choices now?

The second choice in the above answer had been jq, and I agree that it is very powerful.

jq is like sed for JSON data - you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text. There are install packages for different OS.

But comparing to jsonpath it is more difficult to learn to most people, which brings us to the first tool to recommend this time -- jp, because

jp is as simple as jsonpath but as powerful as jq.

How about the rendering engine part?

The problem of both jq or jp is that although they can do data projection in any direction (doing data filtering in any way), their purpose are still focusing on data transformation, but when talking about rendering json data into a format more presentable to human beings, then there is no better tools than easygen. In fact, the easygen is a universal code/text generator that not only works on json data but it can take in data defined in YAML format as well. It can be used as any text (or html, or any other forms) generator for arbitrary purposes with arbitrary data and templates. It is built on top of the powerful Go template engine.

To put them together

So the other day, I

download json data via API
filter the json data with the jp that supports filtering by regular expression (hint: do you know any json filter that when given a video's file name, can tell a tv-series apart from a movie?)
then present the json data in human friendly format with the new easygen that can read from stdin.
in the human friendly form, I need to convert the long number of size in bytes to the size in MB and GB, and I had to search for how to do calculation in Go template, but then was delighted to realized that easygen already supports the calculation in Go template long time ago.

I'll give a more concrete example in the next article.

To me now,

easygen is to json what xslt is to xml, but much more powerful and versatile.

Credit

The cover image is obtained from imd.org.

Maintenance free system multi booting

suntong — Fri, 29 Oct 2021 03:18:03 +0000

The journey continues

First, recap from the previous article, a single grub boot menu entry can be as simple as:

With it, we don't need to hunt for the UUIDs, and we don't need to remember to mount boot partition and update the boot entries any more. It can boot to whatever latest kernel it is, and it will still work even we reformat the partition and install a new Linux, and it will still work even we change the distro from Debian, to Mint, Arch, Fedora, or openSUSE etc.

In this article, we'll first look at those few more boilerplates that enable you to only write the above few lines and everything will work out magically. Then we'll move on to how to make things even simpler, with the help of easygen.

The supporting files

To break free from the rigid format requirement of 40_custom and allow people only write the above few lines, or to order boot entries in the order we want, instead of being determined by their partition orders, we need to build our grub.cfg file from ground up ourselves. And, it is not that scary either and could be really straightforward. Here are all the code it needs:

The grub.cfg file that replace grubs default .cfg file. Deliberately made so simple so that it can be easily restored if it was accidentally overwritten.

The grub-main.cfg that the grub.cfg file actually calls. The idea comes from grml. We can see that it is sourcing a header, a footer, and the main/real .cfg files, like the entry shown above.

Arrange those .cfg files so that their order show up in the order you want in the grub menu. For example, this is how I arrange my grub menu:

I.e., in my preference, I want my grub menu to be in the order of:

My current Linux
Live Linux from ISO, in case I need to check/repair anything
My Windows
My old Linux versions

They are ordered from most probably used to the least probably used. Changing the order is simple, just shift them around in the .cfg text file.

The grub menu's look-and-feel is defined in the header, and the "Shutdown / Reboot" is defined in footer, showing below respectively.

ISO Booting

The bonus and prestige of the whole article, here is how ISO files are automatically discovered and listed:

It can automatically discover and list whatever ISO available on disk:

and boot from them:

The red background color is chosen for the grub menu, to symbolize the live system, and also as the notification sign that this will be the last grub menu level, after which the system will be in booting mode.

Can it be even simpler

So far, we can see that using some simple scripts/configs, we can let the grub to show whatever we want it to show, in whatever order we want as well. Now,

Can it be even simpler?

As pointed out in the "Conclusion" section in the last article, the only things that matter in a grub menu entry are the 'Debian GNU/Linux' and the 'hd0,gpt2', the rest are just the boilerplate that don't normally need to be changed.

What if I only want to specify the 'Debian GNU/Linux' and the 'hd0,gpt2' part, and let the machine to generate the grub menu entry/entries for me? -- Not a problem, if with the help of easygen.

This is all what you need to specify:

Feed that to easygen as:

easygen os2grub-1

then you'll get:

The secret is the easygen's template:

Customize it to whatever you like.

But, most people not just has a single boot menu. How do you deal with that? Simple -- with another small tool of grub2yaml.sh:

Just run it with

grub2yaml.sh /boot/grub/grub.cfg | tee /tmp/myOSs.cfg

Slightly edit it, and you'll get more entries like this:

With multiple entries like that, easygen really starts to shine. You can get the following without a drop of sweat:

Enjoy

IMHO, the way grub2 generates boot entries automatically, at least as of this article is written, is still a big mess. You may not agree with that, but I do enjoy my grub menu system to be plain and simple, straightforward and out of my way. And, I enjoy my freedom to hand-craft my own boot menus again, just like the good old days, but without an extra spare letter to waste.

Hope you enjoy that as well.

Cheers

Journey towards a maintenance free system multi booting

suntong — Thu, 28 Oct 2021 00:05:35 +0000

Problem statement and goal

This article tries to simply the situation for people who dual boot/multi boot their computer systems, be them Debian, Mint, Arch, Fedora, openSUSE, etc, or Windows.

For multi booting all the operation systems, I have a standalone boot partition as well as an UEFI ESP partition. From there, any operation systems on my disk can be booted. A Debian boot entry looks like this:

Let me stress again that this is just one single entry. There are also several "Advanced options" that goes with each Linux system, so my multi-boot grub.cfg file looks scary, because it is humongous. But that's not the only problem.

Problem #1: Because it is in a standalone boot partition, I normally don't need to mount it, but whenever I got my kernel manually or automatically upgraded, I have to remember to mount this partition and update the boot entries there. Otherwise,

I will not be able to boot up my system again, if the old kernels are somehow/automatically purged.
I will not be able to take advantage of the new kernel, even if they have been installed.

Problem #2: I like to bring my 40_custom up to the top of my menu selection, instead of down at the bottom.

Problem #3: I like to order my boot entries in the order I want, instead of being determined by their partition orders.

Although grub can generate boot entries automatically, all above problem are blind spots of grub, and you have to come up with your own ways of dealing with them.

The good news is that the grub.cfg file does not have to be so humongous, scary, and messy. At the end of this article, you'll find that things can be pretty simple. Scroll to the bottom to see if you don't want to go through the discovery journey that leads towards it. I.e. you'll find that

Things can be so simple that people can start writing/maintaining the grub boot menu by hands now. And in the next blog, we can see that things can be even more simpler, with the help of easygen.

Let the journey begin -- we'll going to go through a series of steps to simplify the grub.cfg file so that in the end, they can be edited manually. Now, step number one,

Remove the "Advanced options"

Let's take a look how big my grub.cfg file is:

$ wc /boot/grub/grub.cfg
  355  1338 15006 /boot/grub/grub.cfg

Over 350 lines! Let's first simplify the grub.cfg file by remove the "Advanced options" menu entries, as I've been using Linux for over 20 years, and not a single chance had I ever need to dip into those options. Moreover, the grub menu can be easily edited if I want, say to boot into single mode. They can go for sure:

$ sed '/^submenu .Advanced options for /,/^}/d' /boot/grub/grub.cfg | wc
    183     581    5602

The file size almost dropped in half and now is under 200 lines.

Remove the unnecessary if conditions

Look at the following lines in the above posted grub boot menu:

Has anyone ever wondering what it is doing?

Well, it turns out that

the conditional code checking for this feature is pointless in all modern Linux distributions

So why still keep it around?

These if conditions are second that need to go. After that, a single boot entry will look like:

Remove the unnecessary module loading

Now, why are there so many insmod statements in each boot entry? My computer contains either Linux or Windows, and they reside all in GPT, as ext4 partitions. I.e.,

All my Linux will need the same modules, so it doesn't make sense to repeat every one of them in each individual boot entry.

Can I load all the modules I need only once at the beginning, and save each individual boot entries from repeating themselves?

It turns out that I can. So now my Linux boot entry looks like this:

A little help please

It'll be tedious to go through each boot entry and do the above clean up, so a little help from a script will definitely be the way to go, and here it is:

Toward maintenance free booting

Now it is time to tackle Problem #1 -- whenever my kernel is upgraded, I don't want to

mount my boot partition, and
update the boot entries there

I want my boot partition's boot entries to be able to survive such change and always boot to the latest kernel, whatever they are. Is that possible? Well,

It sure can, using the trick like this:

Maintenance free, at last!

Look at the linux /vmlinuz line, there is still a root=UUID=xxx parameter there. Now what if I reformat the partition and install a new Linux? The UUID will surely change and the above boot entry will surely not be able to survive such change.

This hurdle is the most difficult of all. Luckily someone has already looked into such problem, but sadly, nobody else even care, judging from the up-votes from the SO question and answer. Anyway, here, the prestige of the whole article, here is the solution:

The probe -u $root --set=rootuuid line will set the $rootuuid variable, then it get passed to the next linux /vmlinuz line.

Hooray~~, problem solved!!

One step further

Now, take a closer look at the search --no-floppy --fs-uuid ... line.

What does it do?

It actually set the $root grub variable according to a fixed UUID value on that line, and therefore change the boot partition, which will undermine the whole effort of our above attempt.

That will surely need to go away.

Summary of the journey

The above discovery journey was a step by step one and it has been logged here:

The boot entries were build from the ground up and move step by step to the top. All entries are verified to be working fine.

Conclusion

Once upon a time, people write their own boot menu. But grub2 came alone and people just gave up such practice and rely solely on the machine.

The journey in this article show that things do not have to be that way as the only way -- we can still write our own boot menu, just do not let the humongous file size scare you off, as a single boot menu entry now can be as simple as:

Most of which are boilerplate that don't need to be changed. I.e., the only things that matter are the 'Debian GNU/Linux' and the 'hd0,gpt2'. We don't need to hunt for the UUIDs, and we don't need to remember to mount boot partition and update the boot entries any more. It can boot to whatever latest kernel it is, and it will still work even we reformat the partition and install a new Linux, and it will still work even we change the distro from Debian, to Mint, Arch, Fedora, or openSUSE etc.

There are a few more boilerplates that need to be in place so that you can only write the above few lines and everything will work out magically, which will be covered in next article, with the help of easygen.