OOLOI.ORG
Menu

FRANKENSCORE

A Body Resurrected.

OVERVIEW

DOCUMENTATION

The Musical Journey to Understanding Transducers: Building Ooloi's Piece-Walker

6/6/2025

0 Comments

 
Picture
How solving a real music notation problem revealed the perfect transducer use case

​The Problem That Started It All

I found myself confronting what appeared to be a deceptively simple requirement for Ooloi: 'Resolve slur endpoints across the musical structure'.

Rather straightforward, one might assume: simply traverse the musical structure and locate where slurs terminate. But then, as so often is the case, the requirements revealed added complexity:
  • Slur endpoints must be discovered in temporal order (measure 1 before measure 2, naturally)
  • Yet slurs can span multiple voices on the same staff
  • Or cross between neighbouring staves within an instrument
  • And precisely the same temporal traversal logic would be required for MIDI playback
  • Not to mention visual layout calculations and formatting
  • And harmonic analysis
  • And collaborative editing conflict resolution
Picture
It became apparent that I needed a general-purpose piece traversal utility: something handling temporal coordination whilst remaining flexible enough for multiple applications. Rather than construct something bespoke (and likely regrettable), I researched the available approaches within Clojure's ecosystem.
​
That's when I recognised this as precisely what transducers were designed for.

​The Architecture Recognition

​Allow me to demonstrate the pattern I anticipated avoiding. Without a general traversal utility, each application would require its own approach:
Picture
Three functions, identical traversal logic, different transformations. Exactly the architectural smell I wanted to avoid from the outset.
​
This was precisely Rich Hickey's transducer insight made manifest: "What if the transformation was separate from the collection?"

​The Transducer Revelation

​What if I could write the temporal traversal once, then apply different transformations to it?
Picture
Objective achieved: one traversal algorithm, many applications.
​
But its architectural reach turned out to be even more profound.

​The Architectural Insight

The design decision hinged upon recognising that I was conflating two distinct concerns: the mechanism of traversal and the logic of transformation. This wasn't merely about avoiding the tedium of duplicated code (though that would have been reason enough) but rather about establishing clean architectural boundaries that would serve the system's long-term evolution.

Consider the conceptual shift this separation enabled:
​
Rather than thinking in terms of specific operations upon musical structures:
  • 'I need to find slur endpoints in this piece'
  • 'I need to generate MIDI from this piece'
  • 'I need to calculate layout from this piece'

The transducer approach encouraged thinking in terms of composed processes:
  • 'I need to traverse this piece temporally, then apply endpoint filtering'
  • 'I need to traverse this piece temporally, then apply MIDI transformation'
  • 'I need to traverse this piece temporally, then apply layout transformation'

The traversal thus became reusable infrastructure, whilst the transformation became pluggable logic. This distinction would prove invaluable as the system's requirements expanded.

​The Broader Applications

​What I hadn't anticipated was how broadly applicable the resulting abstraction would prove. After implementing the piece-walker for attachment resolution, I discovered it elegantly supported patterns I hadn't originally considered, each demonstrating the composability that emerges naturally from separating traversal concerns:
Picture
​Each is built from simple, testable pieces. And they all inherit the same temporal coordination guarantee. This composability emerged naturally from the transducer design: a pleasant architectural bonus.

​The Performance Characteristics

As one would expect from a well-designed transducer, memory usage remained constant regardless of piece size: a particularly crucial consideration when dealing with the sort of orchestral scores that might contain hundreds of thousands of musical elements.
​
Consider the alternative approach, which would create intermediate collections at each processing step:
Picture
​The transducer version processes one item at a time:
Picture
​Same result, constant memory usage. This exemplifies what Rich meant by 'performance without compromising composability'.

​Demystifying Transducers

Transducers suffer from an unfortunate reputation for complexity, often relegated to 'advanced topics' when they needn't be. This is particularly galling given that they're fundamentally straightforward when you encounter the right use case, which the musical domain provides in abundance.
​
Think of transducers as 'transformation pipelines' that work with any data source, much as one might design AWS data processing workflows that operate regardless of whether the data arrives from S3 buckets, database queries, or API streams:
Picture
The pipeline stays the same. The data source changes.
​
In Ooloi:
Picture

​Why This Matters Beyond Music

The piece-walker solved a universal software problem: How does one avoid duplicating traversal logic whilst maintaining performance and composability?

This pattern applies everywhere:
  • Web scraping: Same page traversal, different data extraction
  • Log analysis: Same file reading, different filtering and aggregation
  • Database processing: Same query execution, different transformations
  • Image processing: Same pixel iteration, different filters

Transducers provide the infrastructure for "traverse once, transform many ways."

​The Bigger Picture

Building the piece-walker demonstrated that transducers aren't an abstract functional programming concept. They're a practical design pattern for a specific architectural problem: separating the concerns of traversal from transformation.

The musical domain made this separation particularly clear because the temporal coordination requirements are so explicit. When you need the same traversal logic applied with different transformations, transducers provide the elegant answer.
​
This separation makes code:
  1. More testable (test traversal and transformations independently)
  2. More reusable (same traversal, different applications)
  3. More maintainable (one place to optimise traversal performance)
  4. More composable (mix and match transformations)

What's Next?

The piece-walker is documented thoroughly in our Architecture Decision Record for those wanting technical details. But the real value lies not in the musical specifics but in observing how transducers address genuine architectural challenges with apparent effortlessness.

The next time you find yourself contemplating similar data processing logic across multiple contexts, you might ask: 'What if the transformation was separate from the collection?'
​
You may well recognise your own perfectly suitable transducer use case.

References and Further Reading

Rich Hickey's Essential Talks
  • "Transducers" - Strange Loop 2014 - The definitive introduction to transducers by their creator. This talk explains the core concepts, motivation, and design philosophy behind transducers.
  • "Inside Transducers" - Clojure/conj 2014 - A deeper technical dive into the implementation details of transducers, focusing on the internals and integration with core.async.

Official Documentation
  • Clojure Reference: Transducers - The official Clojure documentation provides comprehensive coverage of transducer usage, with examples and best practices.
  • ClojureDocs: transduce - Community-driven documentation with practical examples of the transduce function.

Educational Resources
  • "Can someone explain Clojure Transducers to me in Simple terms?" - Stack Overflow - An excellent community discussion breaking down transducers for beginners.
  • "Grokking Clojure transducers" - /dev/solita - A comprehensive tutorial that builds intuition for transducers through examples.
  • "What if… we were taught transducers first?" - Clojure Civitas - An interesting pedagogical perspective arguing for teaching transducers before lazy sequences.
  • "Using Clojure Transducers: A Practical Guide" - FreshCode - A practical guide with real-world examples and performance considerations.

Advanced Topics
  • "Reducers, transducers and core.async in Clojure" - Eli Bendersky - Explores the evolution from reducers to transducers and their integration with concurrent programming.
  • Rich Hickey Talk Transcripts - Complete transcripts of Rich Hickey's talks, including both transducer presentations, for detailed study.
0 Comments



Leave a Reply.

    Author

    Peter Bengtson –composer, organist, programmer, cloud architect. Currently windsurfing through parentheses.

    View my profile on LinkedIn

    Archives

    June 2025
    April 2025
    March 2025
    September 2024
    August 2024
    July 2024

    Categories

    All
    Architecture
    Clojure
    CLOS
    Common Lisp
    Documentation
    Finale
    FrankenScore
    Franz Kafka
    Functional Programming
    Generative AI
    Igor Engraver
    Jacques Derrida
    JVM
    Lisp
    Ooloi
    Python
    Rich Hickey
    Road Map
    Scheme
    Sibelius
    Site

    RSS Feed

Home
​Overview
Documentation
About
Contact
FrankenScore is a modern, open-source music notation software designed to handle complex musical scores with ease. It is designed to be a flexible and powerful music notation software tool providing professional, extremely high-quality results. The core functionality includes inputting music notation, formatting scores and their parts, and printing them. Additional features can be added as plugins, allowing for a modular and customizable user experience.​
  • Home
  • Overview
    • Background and History
    • Project Goals
    • Introduction for Musicians
    • Introduction for Programmers
    • Introduction for Anti-Capitalists
    • Technical Comparison
  • Documentation
    • Architectural Decision Log >
      • Choice of Clojure
      • Separation of Frontend and Backend
      • Adoption of gRPC
      • Plugins
      • STM for Concurrency
      • JavaFX & Skija
      • SMuFL
      • Nippy
      • Vector Path Descriptors
      • Collaborative Features
      • Trees and Circles
      • Shared Structure
      • Persisting Pieces
      • Slur Formatting
      • Piece Walker
    • Backend src README
    • Development Plan
    • License
    • Code of Conduct
  • About
  • Contact
  • Home
  • Overview
    • Background and History
    • Project Goals
    • Introduction for Musicians
    • Introduction for Programmers
    • Introduction for Anti-Capitalists
    • Technical Comparison
  • Documentation
    • Architectural Decision Log >
      • Choice of Clojure
      • Separation of Frontend and Backend
      • Adoption of gRPC
      • Plugins
      • STM for Concurrency
      • JavaFX & Skija
      • SMuFL
      • Nippy
      • Vector Path Descriptors
      • Collaborative Features
      • Trees and Circles
      • Shared Structure
      • Persisting Pieces
      • Slur Formatting
      • Piece Walker
    • Backend src README
    • Development Plan
    • License
    • Code of Conduct
  • About
  • Contact