tonal-glyph/tgtracker

A music tracker from the future [WIP] Mirror of Gitlab

tonal glyph tracker

IMPORTANT: This project is still in the planning and sandbox phase. Please see Projects and Issues for current progress.

tgtracker will be a digital audio workstation with a tracker-inspired interface. When I originally had the idea, I wanted it to be written in Rust as much as possible. After much research into Rust audio libraries and GUI programming, I've realized that a pure Rust tracker would be very hard to pull off right now with Rust having such a young ecosystem. Ideally Rust could replace C++ in some parts, but frameworks like JUCE are just light years ahead of Rust when it comes to native interfaces and audio routing. Other possible features like VST support, Lua scripting, and Qt widgets also pushed me towards C++. Current sandbox efforts are thus focused on these ends.

Inspiration & History

I first encountered the demoscene in 1996. I used FastTracker and MadTracker to take apart existing modules and make my own. I have wanted since those years to make a tracker of my own. I am new to systems programming so I need all the help I can get for this project. I'm taking inspiration from several existing trackers/DAWs like FastTracker II, MadTracker 2, BuzzTracker, Cockos Reaper, Renoise, and many others.

Goals

• Cross-platform
• Embeddable in game engines/music applications
• Low latency
• MIDI and OSC support
• Portable/serializable data
• Unique interface and document format

Non-goals

• Backwards compatability w/ existing modules (XM, IT, etc.) but import to native format would be nice

License

All libraries and frameworks used to make tgtracker are used under their respective open source licenses.

tgtracker's Issues

Document module

• structure and format
• compression - gzip w/ brotli or zopfli?
• buffers
  • markdown
  • ChucK code See #7
  • Faust diagrams See #11
• pattern data
  • notes
  • envelopes
  • per-note
  • per-channel
  • per-pattern
  • per-document

Node-graph and modular design

Wield the power of nannou, dsp-chain, pcm-flow, sample, etc. to make a graph-based interface using conrod widgets, where everything is potentially a module, and serializable.

Csound

• - Use csound-sys to implement Csound support.

Lua

I’d like to use Lua as an extension language so that much of the functionality can be scripted and others can create their own plugins. This also means using languages that compile to Lua like MoonScript, Wu, and Fennel.

Which version of Lua to target is tricky, probably 5.1 for maximum compatibility.

• - Use include-lua to embed Lua code in Rust code.

SDL

Seems like many trackers these days use SDL, the good ones anyway. Pros? Cons? I know their cross platform footprint is huge, and the language is very concise.

• See #10 for SDL surface discussion
• HID handling vs winit or with winit

DSP

Some resources for audio programming

The Scientist and Engineers Guide to Digital Signal Processing by Steven W. Smith, PhD
Dspguru
katja's homepage on sinusoids,
complex numbers and modulation
Synthesis Toolkit

OpenMPT and other sourcecode bases

OpenMPT is without a doubt an awesome tracker. It can handle almost anything you can throw at it, and it degrades well.

It is however a large codebase of Windows-specific code and I would really like to make a tracker like that which isn't limited to Windows.

The other tracker I'm hoping to learn somthing from is Yannick Delwiche's Madtracker 3, which was never finished. This was essentially a port of Madtracker 2 from Delphi to C++.

You can read about the history of Aldrin, Buzztard, Buzé, and Beast here.

Backends

I would like for tgtracker to support both OpenGL and Vulkan renderers. lyon tesselations can be fed into whichever render backend the user wants to use.

• gfx-hal A high-performance, bindless graphics API for Rust
• lyon 2D graphics rendering on the GPU in rust using path tessellation
• sdl2 Is an SDL surface necessary with this setup? See #6 for SDL discussion in general

gfx

• supported backends
  • gl - agnostic
  • metal - OSX
  • vulkan - agnostic
  • dx11 - Windows
  • dx12 - Windows
• windowing
  • sdl
  • glfw

UI/UX

These all have their pros and cons. conrod is made to be closely integrated with dyon scripts, so that's something to consider.

• imgui
• conrod
• nuklear
• nanovg, which is inspired by HTML5 Canvas

New Logo

Hello sir.
You have a great app, unfortunately this app does not have a logo yet, may I donate a logo for your app?

FAUST

FAUST (FunctionalAudioSTream) is a functional block diagram language for digital signal processing.

Faust can be used w/ ChucK in at least 2 ways:

• faust2ck converts FAUST diagrams to ChucK chugins
• FaucK chugin to inline Faust code within ChucK

Todo:

• Write a C wrapper for libfaust and generate Rust bindings
• Create tgtracker functions to convert FAUST diagrams to various formats
• Tesselate SVG block diagrams w/ lyon for rendering

Literate programming

• Implement literate programming for specs with tango

This sandbox approach is intended to keep the core clean. What works and fits in the specs can then be implemented idiomatically in the core.

Modular design

• document mod - UI gets wrapped around the loaded document

  • pattern editor view
  • graph view
  • mixer view
  • instrument view
  • buffer view

• config mod

• graph mod

  • devices
    • vst
    • au
    • ladspa
    • lv2
    • sound file
    • faust diagram
  • ports
  • connections

• mixer mod

  • channels
  • buses
  • meters

• envelope mod

  • automation
  • ADSR

• dynamic mod

  • REPL
  • livecoding - chuck

• bar mod

• beat mod - beats per bar

• note mod

• pattern mod - notes per pattern

• track mod - tracks per sequence

• channel mod - channels per graph

• sample mod - samples per recording

• sequence mod - patterns per sequence

---

• edge mod
• node mod
• graph mod - graphs per document

---

• instrument mod - phrases, envelopes, devices
• phrase mod - sound files (a.k.a. samples)
• envelope mod - parameter automation
• point mod - points per envelope

---

• device mod - primary device is a sequence player/editor, secondary devices may be plugins or other “machines”
• plugin mod - vst/au/lv2/ladspa/etc.
• socket mod - sockets per device
• direction mod - directions per socket/edge

---

• document mod - song/project, a.k.a. mod or module
• formula mod - a dsp formula that can act as a building block for new statics/dynamics/devices
• static mod - recordings/snippets/scripts in other languages
• dynamic mod - REPL/livecoder/ui
• snippet mod - a block of code to be executed or text node

---

• nodes can have instruments, patterns, sequences, phrases, and edges
• graphs can have sequences, devices, channels
• devices can have plugins, sockets, directions
• sequences can have samples, patterns, notes, bars, beats, tracks, and channels
• channels can have directions, plugins, tracks, sockets
• documents can have formulas, statics, dynamics, snippets, graphs

ChucK

ChucK will be a first class citizen in tgtracker.

• Call ChucK from Rust with ruck
• Call Rust from Chuck with ruck
• Test faust2ck, it generates chugins from FAUST code
• Test FaucK chugin, it processes code
• chuck-sys See https://github.com/tonal-glyph/chuck-sys/issues/2
  • Write C wrapper for libchuck
  • Instantiate ChucK VMs using libchuck
  • Connect libchuck VMs to audio IO
• Create high-level Rust interface w/ chuck-sys and pure Rust libs ruckus

Possible starting point

@cmatsuoka is making a mod player in Rust! Very exciting!

Gwion

Gwion is a strongly-timed programming language inspired by ChucK and written in C. It uses the soundpipe library.

• A binding to libgwion