1
2
3
4
5
6
7

play synth('midi.mid') { |midi|
  midi.env * midi.tone.ramp.filter(
    :lowpass,
    cutoff: midi.frequency + midi.env(range: 300..1200),
    quality: midi.cc(1, range: 2..10)
  )
}

Hey everyone! In this post I want to talk about a long-standing idea in software engineering for making development easier, called domain-specific languages, or DSLs. The term DSL can apply to diagramming layouts, document markup formats, and more, but I want to focus specifically on domain-specific programming languages. In that context, a DSL is a programming language specifically designed for a single purpose or “domain,” like writing web servers, processing audio, creating machine learning pipelines, etc. DSLs are, in my view, the ultimate form of abstraction and expressiveness.

Consider this: when you’re hungry, do you ask for “a saucer-shaped flatbread of roughly 16 inches in diameter, coated with sauce, topped with meat and cheese,” or do you order “a large pizza?” This is how much of a difference there can be between classical approaches to coding and domain-specific languages.

Here’s an example borrowed from later in the article to give you a sneak peek at the advantage a domain-specific language can provide:

1
2
3

get '/' do
  'Hello'
end

1
2
3
4
5
6
7
8
9

class RootController < HttpServer
  def get(request, response)
    if request.path == '/'
      response.body = 'Hello'
    else
      response.status = 404
    end
  end
end

Read on to learn more about domain-specific languages, see how I used Ruby to implement a domain-specific language for audio processing, and compare some real-world DSLs to more traditional programming approaches. My goal is to show you the power of language, abstraction, and Ruby, and if you’re a programmer, convince you to try using and making domain-specific languages yourself.

Back in March of 2025 I started what should have been a straightforward Ruby version upgrade. Little did I know I was about to fall down a multi-day rabbit hole that would ultimately reveal a memory corruption bug (now fixed) deep within core Ruby systems.

Often when you make a typo or miss an operator in code the program simply doesn’t work. But there are those rare cases where you get a subtle, insidious change that appears to work correctly. This is the latter case, with missing parentheses leading to a crash due to memory corruption.

Here’s a bit of foreshadowing (did you know that Ruby has an operator called the flip-flop operator?):

1
2
3

raise 'Invalid channel' if !1..16.cover?(channel)
# vs.
raise 'Invalid channel' if !(1..16).cover?(channel)

Keep reading to see how code coverage, automated testing, uncommon operators, and out-of-bounds array writes all converge in a very unexpected way.

Something you should know about me is that I like to learn about my tools by making them do things they aren’t supposed to do. In line with that, almost six years ago I asked a question (worded slightly differently): Can we use Ruby for sound? As far as I’m concerned, my most recent project continues to answer that question with a resounding, reverberating YES.

In December I live-coded a fully functional reverb effect using Ruby and the mb-sound library I developed for my YouTube video series, and since then I’ve been working nonstop on improving the reverb and making a video about it.

This latest video, inspired by a presentation at ADC21, uses data visualization and animation to explore the concept of reverberation, my implementation of the reverb design from that presentation, and the debugging process required to get the reverb working live. You can check out the video on YouTube, or continue reading here for some extra backstory and a complete video transcript.

Hey there, everyone! This is just a quick post to share a debugging technique I’ve found useful and that I recently added to mb-util. Today I’m talking about using SIGQUIT to trigger some kind of debugging action in an application, such as opening a REPL or logging a stack trace.

The reason SIGQUIT is useful is that most terminals will send that signal if you press Ctrl-\ (control and backslash), and many server environments also have a mechanism for sending UNIX signals.

I’m not the first person to do this of course. My inspiration comes from the JVM, where SIGQUIT will print stack traces and JVM statistics, but I believe the idea goes back further. Here I’ll show how to apply this concept to a Ruby application, but you can do the same thing in any language.

Over the years of my engineering career I’ve been involved in a number of monitoring, observability, and visualization projects. I’ve found that many of my system-oriented techniques learned from across industries aren’t always intuitively obvious to newer engineers, so I’ve wanted to write about the subject for some time. Here you’ll find my thoughts on observability, instrumentation, monitoring, etc.

The key insight for me has always been looking at any given system as a system in the abstract sense. A system of any kind has an intended (or emergent) purpose, various inputs and outputs, and a number of interconnected components. Each component can in turn be viewed as a system and further subdivided. It is this layered breakdown of a system into components, and the connections between them, that guides my approach to system observability.

Continue reading to find my take on what I mean by “observability,” what the goal of observation is, and how I approach instrumenting a system. I’ll provide examples from different types of system, and compare them to software systems.

Once again it’s time for another episode of my video series, Code, Sound & Surround! This series is all about using 2D and 3D visualizations, code, and sound to explore the relationships between math, sound, visuals, and problem solving from a unique angle. My goal is not necessarily to be a one-stop source to learn these concepts, but rather to both provide an overview of things you might not have heard of, and to present familiar concepts in an unfamiliar way, to help unlock new insights and reveal the connections between ideas.

This time we’re reviewing how sound is digitized, quickly recapping filters, and looking at the Fast Fourier Transform (FFT) with some never-before-seen 3D visualizations. The video also briefly introduces analytic signals and sets the stage for future videos that will dive further into analytic signals, synthesizers, and surround sound. And don’t miss the synthesizer demo song at the end, showing just how much can be accomplished with a few stages of simple signal processing.

As part of working on this video, I’ve made hundreds of commits and added thousands of lines of code to mb-math, mb-util, and mb-sound, so check those out as well. Also, all music from all of my videos is original, either composed for this video series, or repurposed from my previous work.

Keep reading below for the video’s backstory, a list of the concepts covered in the video, and a transcript of the video.

My latest video is live on YouTube! In this beautifully animated tour of Voronoi diagrams, Delaunay triangulation, and natural neighbor interpolation, I explain the algorithms used in my mb-geometry rubygem for generating Delaunay triangulations and Voronoi partitions. Then interpolation is given as a practical application of these algorithms.

This video is part of my ongoing video series, Code, Sound & Surround.

You can keep reading for a partial transcript of the video, and I’ve written more about Voronoi partitions, Delaunay triangulations, and mb-geometry previously.

I’ve been writing a lot of code for my next video in Code, Sound & Surround. One small part of that has turned out to be interesting enough to show off on its own. I built some tools for plotting and animating Voronoi diagrams in Ruby, and now I’ve published them on GitHub.

Update: I’ve also made a YouTube video showing these geometric algorithms.

A Voronoi diagram (Voronoi rhymes with “enjoy”) or Voronoi partition shows which areas are closest to a set of starting points. Choose one or more points on a 2D plane (you can also do 3D or higher, but I haven’t done that). Draw a convex polygon around each point, showing the area that is closest to that point. That’s a Voronoi diagram.

Each edge of a polygon should be half-way between two points, and each corner of a polygon is equally distant to three or more points. Every polygon has one point inside it, and every point has one polygon around it, with no overlap. Give each surrounding polygon its own color, and you get something like this:

Ruby is one of those programming languages that seems to get slotted into a specific use-case in people’s minds. You use Ruby for web development, C or C++ for high-performance code, Java for banks and insurance companies, Python for machine learning, Rust for trendily secure code, Typescript for web frontends. Everyone just “knows” these things. But why?

For a long time I had wanted to make my own A/V receiver with my own audio algorithms. Most people just buy a TV and call it done. Some people will buy a TV and a sound bar and call it done. A few more will buy a TV, a receiver, and some speakers and call it done. And the super dedicated (or super rich) will buy an expensive hi-fi system and/or home theater. But not me. Instead of just buying a receiver and pushing that “Dolby” or “DTS” button, why not do things the hard way, and make my own?

Put those two things together – my love of Ruby, and my love of sound – and mix in a bit of 2020 lockdown. I just had to prove that Ruby is good for more than web development. I ended up writing my own stereo-to-surround-sound decoder (more than one, in fact), and a bunch of other audio code, all in Ruby. Not content with that, I’ve released a lot of my code on GitHub and I’m making videos to teach others about sound, and about Ruby.

This series of videos and posts is all about my journey to find out just what Ruby is capable of, and to make the best-sounding surround decoder ever written in Ruby.

I’ve been working hard on a YouTube project lately, which I’ll blog about later. For now, I’m pleased to announce that I’ve opened up the source code for Nitrogen Logic’s Depth Camera Controller browser-based UI, called knc.

knc is a Ruby- and EventMachine-based service that serves a dynamic browser-based UI (HTML, CSS, JS) for controlling Nitrogen Logic automation systems and Philips Hue lights using the Kinect.