As any Linux chat room or forum will tell you, the most powerful tool to any Linux user is a terminal emulator. Just about every program under the sun has a command line alternative, be it CAD, note taking, or web browsing. Likewise, the digital audio workstation (DAW) is the single most important tool to anyone making music. Therefore, [unspeaker] decided the two should, at last, be combined with a terminal based DAW called Tek.
Tek functions similarly to other DAWs, albeit with keyboard only input. For anyone used to working in Vim or Emacs (we ask you keep the inevitable text editor comment war civil), Tek will be very intuitive. Currently, the feature set is fairly spartan, but plans exist to add keybinds for save/load, help, and more. The program features several modes including a multi-track sequencer/sampler called the “arranger.” Each track in the arranger is color coded with a gradient of colors generated randomly at start for a fresh look every time.
Modern audio workflows often span across numerous programs, and Tek was built with this in mind. It can take MIDI input and output from the JACK Audio Connection Kit, and plans also exist to create a plugin server so Tek could be used with other DAWs like Ardor or Zrythm. Moreover, being a terminal program opens possibilities for complicated shell scripting and other such Linux-fu.
Maybe a terminal DAW is not your thing, so make sure to check out this physical one instead!
I’ve also found two similar projects:
https://github.com/danfrz/PLEBTracker
https://zuggamasta.de/projects/miditracker/
I was just about to write that tracker style MIDI sequencer would be really cool. Need to check those. I am recently to go back to trackers as my hobby. AXS and Renosie are on my list. Those two trackers you linked look like real time thieves! THANKS!
About TEK – I simply love the way it looks. Need to try it one day. I didn’t go into details but it looks more like MIDI sequencer than DAW, although github readme file says something about sampling. This could be something that will gather a stable scene.
author here. thanks for your kind words! midi sequencer just about covers the current (alpha) version. i’ve prototyped sampling and lv2 plugin hosting over the past year and plan to release them over the coming weeks — as i clean up the architecture and make it possible to add a more linear daw-like workflow with a focus on takes/comping.
This is intriguing. I played around with something called NonDAE years ago. The idea of basically getting the UI out of the way so the focus would be on the music production. This sounds a bit different. I would love to see a new method of representing audio in the CLI. I think it would be possible with different levels of “magnification” and good “start” “stop” markers for region selections that could be beat, time, or sample accurate. Maybe also a way of determining where one wants to select, audibly. Kind of a “loop what is visible” approach and then the user taps a key to drop the marker (start or stop) and then has the freedom to move the marker to the left or right until it is perfect. Anyway… Just me brainstorming how I would do it. Interested to see what you wind up doing.
“For anyone used to working in Vim or Emacs (we ask you keep the inevitable text editor comment war civil)”
Ok, fine. I’ll accept a temporary ceasefire with the Vim people. But you didn’t say anything about us gaining up on the Edlin fans!
Sed is the only choice.
YOUR EDITOR SMELLS OF ELDERBERRIES!
** feverish flapping of gauntlets on ramparts ***
U so hard-core. 🤣
I’m honestly impressed there are still emacs users out there. I’ve met a lot of vim people but never an emacs person. OSS Code for the win though..
First used emacs on multics c1981. Still using it today; I’ve tried other editors and IDEs, but always come back…
Am I the only one who use mcedit?
Editor? How about IBM 029 keypunch? Kids.
This is an exceptional text UI. Seems like the Rust ecosystem has that nailed down. Looks too cool to not play with!
a pretty weird idea. i’m not convinced this is a good way to go, though i’m curious how the keyboard commands work.
i’ve played a little with multi-track recorders (a subset of DAW functionality). my first one was command-line driven (unlike Tek). the commandline was text but then the display for the tracks was in a graphical window. so you would have to have two windows open, one with the terminal and one with the display. maybe i could have invented a better commandline syntax, but i found it way too cumbersome to work with. but it was the program i had so i used it for years whenever i would need to cut up a sample.
i met a version of Traverso…when i discovered it, it was buggy as heck and it was in the process of being rewritten into a more normal DAW interface (yet another unneeded audacity clone). but the one i used, like to adjust the master volume on the track, instead of mousing onto a tiny skeuomorphic knob, you would simply mouse over any part of the track and then hold down a key (maybe ‘v’olume) and move the mouse up and down while holding the key. i thought that was brilliant.
i resigned myself to using audacity, but the closest USB jack to my microphone is a raspberry pi, and the raspberry pi kernel drivers are just thin wrappers around buggy closed source garbage. so – surprise! – audacity hard-locked my pi when it tried to enable DMA mode on a USB sound device. rather than figure out how to get audacity to give up on DMA before the pi firmware eats itself, i wrote a new multi-track recorder.
the new one has basically the old traverso interface. hold down a key and drag the mouse to change a setting. it’s modal depending on where the mouse cursor is, whether it’s in a track or not. there’s a uniform way to enter the value with the keyboard (numeric). and its best feature, a modal help screen that shows the keys for the current mouse position. it’s a rare one for me, in that it is both very easy to use once you know it, and very easy to learn (or to pick up again after forgetting how it works). and it’s intentionally very simplistic (trying to give you basically just cut-and-paste with tape).
the point i’m trying to circle is that what is needed is an input interface that takes advantage of the keyboard and doesn’t have the user practicing their fine clicking skills on skeuomorphic garbage. having a terminal display is actually not any benefit at all. and anyways, Tek doesn’t seem to have a commandline so it doesn’t seem amenable to scripting. i’d love to see an article summarizing the Tek keyboard commands but the screenshots make it look like a 1990-era mod tracker, rather than a multi-track recorder?
thanks! some absolutely valid points and some great ideas in your post.
people have asked me before whether they could use a rpi to replace a multitrack recorder. if your program is publicly available i’d be happy to try it out, and recommend it should the question comes up. personally, the main thing i’ve been trying to replace and extend is ableton live’s loop-based “session view” – a feature that’s gradually osmoting into other daws such as ardour and bitwig.
the main benefit for targeting text terminals is the reduced complexity. i’m absolutely not a designer, so i could spend an eternity just fiddling with a pixel-based design to make it acceptable to my ingrained preconceptions about ui aesthetics, then abandoning it once i realize i’ve spent an eternity on an interactive mockup. building for a text grid enabled me to focus on building actual features, of which several will be released over the coming weeks (including online help on f1). some pocs of sampling and plugin hosting can be seen at https://v.basspistol.org/c/tek/videos
of course having pixel resolution is helpful when trying to represent more granular data, such as audio samples or midi notes. the “framework” underlying tek is called tengri (https://codeberg.org/unspeaker/tengri), and is generic over the backing implementation. currently it only supports ratatui for rendering to a terminal. however, once i’m happy with the general workflow and behaviors, and once i’ve found a satisfactory graphics backend (egui? opengl? webgpu? idk yet!), it should be smooth sailing to provide full graphics.
you are correct that in its present state tek is not scriptable. however the key bindings and the interface layouts are defined in a custom edn-like dsl, which i also plan to extend, with the ultimate goal of making the application and contained project live-editable.
Is it still CLI if you’re emulating a graphical user interface with ASCII graphics?
The answer is no. This is a class of interface that is called TUI or Text-based User Interface. The definition of a pure CLI program is a bit muddled but this is 100% a TUI program and not a CLI program.
Especially when you have drop-down menus labeled “file” or “edit” on the screen, which was common in the era of DOS applications where you could actually use a mouse to access them if you had the hardware and the drivers loaded. At that point, the boundary between a CLI or a “TUI” and a GUI is very muddled.
Holy Moly! If graphics like that can be done in a standard-enough (cross-platform) manner, via terminal-emulators, alone, I might break free of my ASCII UI’s!
This could be great for squeezing out every bit of performance of the machine since it doesn’t need to run a graphical desktop manager like gnome or xfce. Also no need for Wayland to be running at all and it can be accessed remotely over ssh. I approve.
Don’t know about DAW, but I do know a little about MIDI, including the representation of MIDI in a RIFF file. In an earlier century, I wrote a small application to edit MIDI files, called Score. You open the file, and it translates it into human-readable representations of each event, presented in an editable text box. You can edit this, or you can create one from scratch with this, and save it in a MIDI RIFF file. It couldn’t even play the files – the assumption was that you have another app for that. Perhaps Tek would do. I don’t know – I couldn’t get a sense of how the user interface works from the README.
I’m not sure why terminal applications are called terminal emulators. What does a terminal do? It converts keypresses into an ASCII (or perhaps Unicode) stream, an simultaneously converts an text stream into a human-readable visual display. Which is exactly what a terminal emulator does. So how is that not just a terminal? I mean, you can make a Teletype Model 33 ASR emulator, and you can make an ADM-3a emulator, but unless you’re duplicating the characteristics of some specific existing device, it’s not an emulator. It’s just a terminal. You wouldn’t call a word processing app a document editor emulator, or a modern automobile a jalopy emulator.
A computer program is not a terminal – it’s code running on a CPU. A terminal is (originally) a state machine implemented in discrete logic that stores and sends data into a character generator with a fixed character memory, and sends out any key presses by the user. It has no CPU and no program code.
A computer program or application that implements the function of a terminal is emulating the logic of a particular terminal as it is implemented in the hardware, sometimes even down to the physical timings and other quirks, so it’s called a terminal emulator.
That’s what it’s doing. An emulator is hardware or software that makes one computer system behave like another system, so when you’re implementing the state machine that answers to the control codes in a computer program, you’re building a virtual version of the hardware inside a different type of machine, which is called emulation.
I have to disagree. MOST terminals are computer programs, even though the dedicated ones won’t run any other program. The DEC VT-220 was definitely not discrete logic state machines; it was literally code running on a microprocessor, but you wouldn’t call that a terminal emulator.
The early terminals didn’t run any program. The later ones did have CPUs but those were then dubbed “smart terminals” to distinguish them from the old “dumb terminals”.
You could.
I mean, the physical hardware is the terminal, but if it also happens to be a programmable computer that can emulate other terminals, then it is also a terminal emulator – or rather, the program that it’s running is the emulator.
Or, if the thing that you’re calling a “terminal” actually happens to contain a programmable CPU doing the business then what you’re dealing with is really a computer that is running a terminal emulator program.
The point of the terminal was that it wasn’t a computer in itself – it was a remote display unit for a computer. The later terminals that were actually computers were merely called terminals by their use, and then became “computers” when the user could enter their own programs.
The key here is that each character encoding, be it ASCII or ANSI or some proprietary set contains a bunch of control characters as well as the displayable text characters. A terminal emulator is programmed to be the machine that the control protocol was designed for: it’s a virtual implementation of the machine described by the standard as opposed to a hardware implementation of it.
The terminal emulator program on your Linux desktop too is implementing one or many of those standard protocols, which is how you get these “text graphics” to display. The actual program you’re using is sending sequences of control codes that set things like character color or cursor position, and the terminal emulator handles the display logic as if it were a real physical terminal. But it’s not – it’s a kind of virtual machine, hence why we call it an emulator.