There's a belief hardwired into the dev community that says if you can solve something with software, solving it with hardware is a vanity project. Even worse: if you can solve it with a $3 LCD, building a pneumatic mechanism with actual physical movement is straight-up something a person with way too much free time would do.
With all due respect: that take is pretty wrong.
I watched the Air Powered Segment Display video and I just stopped. A seven-segment display where each segment is a small physical flap that lifts with compressed air. No LEDs. No pixels. No framebuffer. Just air pressure, solenoid valves, and the sound — that sound — of something physical moving to show you a number.
My first instinct was the usual one: why, though? I have a Raspberry Pi that can do the same thing with two lines of Python and a $4 display from AliExpress.
Then I thought about the dancer with ALS controlling a performance with brainwaves, and something clicked.
Pneumatic display as artistic hardware: what the digital stack can't give you
We're so deep in abstractions that we forget something fundamental: information has weight.
Not metaphorical weight. Literal weight. When a segment lifts with compressed air, there's mass moving. There's inertia. There's a small delay that isn't a bug or a hardware limitation — it's physics. It's the universe doing its thing.
An LCD shows you the number 8 in zero milliseconds. A pneumatic display shows you the number 8 after each segment decides to rise, with that valve click that's impossible to ignore.
Which one communicates better? Depends on what you want to communicate.
If you want efficiency: LCD, always. If you want the person to feel the data — to have the number occupy real space — the pneumatic one wins without argument.
Something similar happened when I built the sonification of Buenos Aires buses. The GTFS-RT data is the same data any tracking app uses. But when the data becomes sound in real time — when you hear a bus passing instead of seeing it on a map — something changes in how you process the information. I wrote about it in the sonified buses post and I still keep coming back to it.
How a pneumatic segment display works (and why it's more complex than it looks)
The basic mechanics are deceptively simple:
┌─────────────────────────────────────────────────────┐
│ PNEUMATIC DISPLAY - BASIC ARCHITECTURE │
│ │
│ Compressor → Manifold → Solenoid valves (7x) │
│ ↓ │
│ Physical segments │
│ (flaps/paddles) │
│ ↓ │
│ Controller (Arduino/ESP32) │
│ decides which ones to fire │
└─────────────────────────────────────────────────────┘
But when you start thinking about it like a software architect — which is how I can't help but think about everything — interesting problems show up:
# This looks simple but hides real complexity
# An LCD would do this instantaneously
# A pneumatic display has to handle:
# 1. Valve opening time
# 2. Valve closing time
# 3. Residual pressure
# 4. Conflicts if you change the number too fast
SEGMENTS_PER_DIGIT = {
# Format: (a, b, c, d, e, f, g)
# a=top, b=top-right, c=bottom-right,
# d=bottom, e=bottom-left, f=top-left, g=middle
0: (1, 1, 1, 1, 1, 1, 0),
1: (0, 1, 1, 0, 0, 0, 0),
2: (1, 1, 0, 1, 1, 0, 1),
3: (1, 1, 1, 1, 0, 0, 1),
4: (0, 1, 1, 0, 0, 1, 1),
5: (1, 0, 1, 1, 0, 1, 1),
6: (1, 0, 1, 1, 1, 1, 1),
7: (1, 1, 1, 0, 0, 0, 0),
8: (1, 1, 1, 1, 1, 1, 1),
9: (1, 1, 1, 1, 0, 1, 1),
}
# The real problem: how do you transition between digits
# without segments colliding with each other?
# Do you cut everything off and then fire the new number?
# Or do you calculate the delta and only move what changed?
def calculate_segment_delta(current_digit, new_digit):
"""Calculate which segments actually need to move (not all of them)"""
current_state = SEGMENTS_PER_DIGIT[current_digit]
new_state = SEGMENTS_PER_DIGIT[new_digit]
activate = []
deactivate = []
for i, (current, new) in enumerate(zip(current_state, new_state)):
if current == 0 and new == 1:
activate.append(i) # This segment rises
elif current == 1 and new == 0:
deactivate.append(i) # This segment drops
return activate, deactivate
# Going from 8 to 1:
# Need to drop: a, d, e, f, g
# Need to raise: nothing (b and c were already up)
# Five valves fire almost simultaneously
# The sound that makes is impossible to replicate in software
That last comment isn't poetic — it's technically relevant. The sound is information. The click of five valves closing at the same time tells you something a pixel change cannot.
It's the same reason AMBA trains playing music have something that an animated map doesn't. I dug into this in the open data and trains post: when data has temporal and physical dimension, it changes how we process it.
The common mistakes people make when thinking about artistic hardware
Mistake 1: "It's inefficient, therefore it's bad"
This is the biggest trap. I spent years thinking about computational efficiency as a universal metric. After 32 years in tech, I can tell you: efficiency is one metric among many. A pneumatic display is terribly inefficient in terms of energy, speed, and cost. It's also irreplaceable if you want someone to feel the data.
Same argument I make when I talk about technically perfect programming languages that nobody adopted: technical perfection doesn't guarantee adoption or impact. Humans aren't compilers.
Mistake 2: "It doesn't scale"
Correct. And? Not everything has to scale. A pneumatic display isn't competing with Times Square. It's competing for the experience of making one person stop and actually pay attention.
Mistake 3: "It's nostalgia dressed up as art"
I'm more careful here. It can be nostalgia. But there's a real difference between nostalgia and an informed choice. Someone who builds a pneumatic display in 2025 knows LEDs exist. The choice is deliberate.
I wonder if those of us living in the digital stack — Docker, PostgreSQL, APIs, abstractions on top of abstractions — have lost some of that contact with the physical that these projects recover.
Mistake 4: Underestimating the control complexity
Solenoid valve control with precise timing, pressure management, physical signal debouncing — this isn't simpler than software. It's different. The bugs are literally audible. A segment that doesn't drop all the way is visible from three meters away. There are no logs, no stack trace, just a physical segment that didn't do what you told it to.
Reminds me of when I wiped the production server with rm -rf in my first week working with Linux, at 19. Physical errors have a different quality — they're undeniable, they're right there, in real space.
Mistake 5: Believing AI will make it irrelevant
I've seen a lot of arguments that generative AI is going to make artistic hardware obsolete. Same argument people made about Apple and on-device AI: the obvious prediction is usually the wrong one. The physical and unrepeatable gains value precisely as the world fills up with generated content.
FAQ: Pneumatic displays and artistic hardware
What exactly is a pneumatic segment display?
It's a seven-segment display where each segment is a physical moving part — usually a flap or paddle — that rises or drops via compressed air pressure controlled by solenoid valves. Unlike an LED display where segments are electroluminescent, here each segment has real mass, moves through space, and produces sound. The controller (typically Arduino or ESP32) fires the corresponding valves based on which digit you want to show.
Is it practical for real use or is it just art?
Depends on what you call "practical." For displaying data quickly at low cost, no, it's not practical. For installations where you want information to have physical presence — museums, performance spaces, interfaces that want to communicate weight and deliberation — it's perfectly practical. The right question isn't whether it's efficient, it's whether it achieves the communicative goal.
How much does it cost to build one?
No fixed number, but the main components are: small air compressor ($30–80), 12V solenoid valves ($3–8 per valve, you need at least 7), pneumatic tubing, the physical segment mechanism (usually fabricated with 3D printing or laser cutting), and the microcontroller. A single-digit prototype could run $150–300 in materials. The real cost is design time and mechanical tuning.
What microcontroller is recommended for controlling the valves?
Arduino Uno or Mega for simple projects — low cost, easy to debug. ESP32 if you want WiFi connectivity to update data remotely, which is useful if you want to display real-time feeds like temperature, prices, or any live data source. The control logic is straightforward: digital out per pin fires the valve. The complexity is in the timing for smooth transitions between digits.
Why would anyone choose this over a digital display in 2025?
Several non-exclusive reasons: the complete sensory experience (sound + movement + physical presence), the deliberate contrast with the omnipresence of screens, the quality of attention it generates in the viewer, the uniqueness of the object, and honestly — the pleasure of building something with real physics. There's something about watching a segment rise with air that no CSS animation is going to replicate. I also think there's a response to digital content saturation happening: the physical and unrepeatable is gaining value.
Is there an active community for this kind of artistic hardware?
Yes, though scattered. Hackaday is the main hub — projects like this show up there regularly. r/DIY and r/electronics on Reddit. The generative art community has overlap with artistic hardware, and platforms like Instructables document similar projects. The artistic hardware community is niche but it's not alone — and it's growing.
What this video left me thinking about
I'm someone who lives in the digital stack. My recent projects are all software — Next.js, TypeScript, PostgreSQL, Docker running on Railway. The only time I touch hardware is to diagnose why my homelab won't come up.
But there's something about these artistic hardware projects that gives me a productive kind of discomfort. The same discomfort I felt with the dancer with ALS. The same I feel when I sonify transit data and people prefer to hear the buses rather than watch them on a map.
I think the people choosing the physical and the slow aren't being nostalgic or inefficient. They're making a statement about how they want to relate to information.
In a world where everything is instant and frictionless, something that requires air pressure, valves that click, and a full second of delay to show you a number — that's a philosophical choice. They're saying: this data deserves weight. It deserves space in the real world. It deserves to make you wait for it.
I don't know if I'm going to build a pneumatic display. I do know I'm going to keep thinking about the question it raises: what do we lose when we make everything faster, more efficient, more digital?
The compressed air lifting a segment doesn't have an answer to that. But it asks the question in a way no pixel ever could.
