<figure><img src="image_1.png" /></figure>

HAL
open science

# Bridging Musical Gesture and Computational Representation: Designing Gesture Composition Framework

Marco Matteo Markidis

<figure><img src="image_2.png" /></figure>

## To cite this version:

Marco Matteo Markidis. Bridging Musical Gesture and Computational Representation: Designing Gesture Composition Framework. Proceedings of the 19th Linux Audio Conference, Jun 2025, Lyon, France. hal-05096021

HAL Id: hal-05096021

https://hal.science/hal-05096021v1

Submitted on 3 Jun 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_3.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# BRIDGING MUSICAL GESTURE AND COMPUTATIONAL REPRESENTATION:
DESIGNING GESTURE COMPOSITION FRAMEWORK

Marco Matteo Markidis

Independent Researcher
Parma, Italy

mm.markidis@gmail.com

## ABSTRACT

By designing the Gesture Composition Framework (GCF), the author aims to introduce a novel computer-based composition framework that treats musical gestures as first-class citizens in the compositional process, enabling composers to work at a higher level of abstraction than traditional signal-processing approaches. Unlike traditional frameworks that focus on synthesis parameters or signal flow, GCF represents gestures as complete musical ideas with temporal evolution, enabling a more intuitive mapping between musical intention and computational representation. This paper presents an embedded domain-specific language (EDSL) in C++ that leverages modern language features to provide both expressive power and compile-time safety. The framework's key innovations include a gesture-centric approach to composition, rich parameter evolution trajectories, pattern-based temporal structuring, and strict type validation through C++ concepts. Through quantitative analysis, we demonstrate how GCF maintains a significantly higher Conceptual Mapping Ratio indicating a closer alignment between musical concepts and implementation elements. These preliminary results confirm that GCF effectively has the potential to bridge the gap between traditional musical thinking and computational implementation, offering composers a powerful new tool that combines intuitive expression with technical precision.

## 1. INTRODUCTION

### 1.1. Computer-Based Composition Approaches

Electronic music composition has evolved through multiple paradigms since the early experiments with tape music in the 1950s. Contemporary approaches to scoring and composing computer-based electronic music can be broadly categorized into four main paradigms:

1. Text-based languages (CSound, SuperCollider, OpenMusic) that offer precise control through programming constructs but often require composers to think in terms of low-level synthesis parameters.

2. Visual programming environments (Pure Data, Max/MSP) that provide intuitive interfaces through graphical patching but may become unwieldy for complex compositional design.

3. Traditional notation extensions (Finale with NotePerformer, Bach library for Max) that augment conventional music notation with electronic music symbols, which maintain familiarity but struggle to represent the full complexity of lower-level processes (sound synthesis).

4. Digital Audio Workstations (DAWs) that offer timeline-based editing and parameter automation but tend to enforce a track-based mentality that may not align with more experimental compositional approaches.

Each approach offers distinct advantages but also imposes specific constraints. Text-based languages provide precision and

algorithmic capabilities but often hamper intuitive musical expression. Visual environments offer immediacy and experimental freedom but may lack rigorous structural validation. Traditional notation maintains connection with classical training but struggles to represent timbres and transformations. DAWs excel at production but may constrain compositional thinking to conventional structures.

### 1.2. Motivation and Scope

It is important to distinguish between synthesis frameworks and composition frameworks in computer-based music creation. Synthesis frameworks primarily focus on sound generation techniques, signal processing algorithms, and audio parameter manipulation. Composition frameworks, by contrast, emphasize the organization and structural representation of musical ideas, providing abstractions for expressing temporal relationships and musical intent. While GCF includes synthesis capabilities through audio nodes, its primary contribution lies in compositional representation and organization rather than sound generation techniques.

In the following paper, a 'gesture' refers to the smallest meaningful unit of musical expression from a compositional perspective—a computational primitive that encapsulates musical intent with temporal evolution<fnref n="1" />. This definition focuses on the compositional representation of complete musical ideas rather than physical movements or performance actions. A gesture in our framework represents a unified concept that includes duration, parameter trajectories, and relationships to sound-producing entities, enabling composers to work with musically meaningful units rather than individual synthesis parameters.

This paper introduces the Gesture Composition Framework (GCF), a computer-based composition framework designed to bridge the gap between musical thinking and computational implementation.

Current computer-based composition environments excel in their respective domains but present challenges when composers need to work at higher levels of abstraction. GCF treats musical gestures as first-class citizens in the compositional process, providing abstractions for composers who conceptualize music in terms of gestural units with temporal evolution. Also, GCF enables these composers to express temporal musical relationships through gesture-centric organization.

GCF serves as a computer-based composition framework, emphasizing the computational foundation while maintaining applicability beyond traditional computer music contexts. The framework's design accommodates various output modalities—from direct audio synthesis to potential integration with notation systems or control data for traditional instruments.

### 1.3. Paper Outline

The remainder of this paper reviews related work in computer-based composition tools and embedded DSLs (Section 2), pre-

<footnote n="1">¹This computational definition resonates with F. Nicolas's conception of gesture as "a particular kind of musical moment, which is generally clearly identifiable... because it contains a form and a cut-out that are obvious both on reading the score and on listening" (cited in [6], Appendix B.4.a, translated by Cadoz & Wanderley).</footnote>
sents the conceptual framework underlying GCF (Section 3), details the embedded DSL design and implementation (Section 4), evaluates the framework through quantitative analysis (Section 5), and concludes with contributions and future directions (Section 6).

# 2. RELATED WORK

## 2.1. Current Computer-Based Composition Systems

### 2.1.1. *Pure Data and Max/MSP*

Pure Data (Pd) and its commercial counterpart Max/MSP represent the paradigm of visual programming for electronic music. Developed by Miller Puckette [1], these environments allow composers, RIM and sonic artists to create music through graphical "patches" of interconnected objects. The visual nature provides immediate feedback and an intuitive understanding of signal flow, making these tools popular for both composition and live performance.

Puckette himself acknowledges in [2] that these visual programming environments were primarily designed as real-time scheduling and interconnection systems rather than comprehensive composition tools. He notes that Max paradigm environments are effective for connections and interconnectivity, and they focus on processes rather than data. Additionally, they do not offer any native concept of event. These limitations directly impact the expression of complex musical gestures, which often require sophisticated transformations of parameters over time.

### 2.1.2. CSound and Text-based Languages

CSound, developed by Barry Vercoe at MIT [3], exemplifies the text-based approach to electronic music composition, separating instrument definitions (orchestra) from event sequences (score). SuperCollider [4] extends this with a real-time, object-oriented approach.

These systems offer precision and algorithmic capabilities but often require composers to think in terms of technical implementation rather than musical gestures. As Lansky [5] observed, "the composer must become fluent in both the language of music and the language of the computer," creating a dual cognitive load with a consequent inherited loss of time. While excelling at sound synthesis definition, these systems provide less support for expressing complex parameter evolutions and temporal structures as unified entities.

## 2.2. Prior Academic Work on Gesture-based Composition

The concept of musical gesture has received considerable attention in music research. Cadoz and Wanderley [[6] compare various definitions of gesture, where some of these refer to musical gesture as "a temporal process where movements reference both action and meaning," highlighting its foundational role in musical expression.

Several systems have attempted to address gesture in electronic music: OM-Chroma [7] and DISSCO [8] both introduced hierarchical approaches to composition that include gesture-like constructs. OM-Chroma integrates sound synthesis with compositional structures, while DISSCO uses a hierarchical organization. However, both systems maintain separation between their gesture concepts and the actual synthesis process, creating workflow discontinuities.

Baalman [9] proposed WFSCollider for spatial sound control, but its gesture concept primarily addresses performance rather than composition structure.

While these contributions recognize the importance of gesture, they typically treat it as an additional layer on top of existing paradigms rather than as the fundamental organizing principle of the composition environment.

## 2.3. Embedded Domain-Specific Languages

Embedded Domain-Specific Languages (EDSLs) combine the expressivity of specialized languages with the tool support of host languages. In the music domain, ChucK [10] provides a specialized language for audio programming but lacks C++'s compile-time guarantees. HMusic [11] leverages Haskell's functional paradigm<fnref n="2" /> for musical patterns and multi-track compositions. The potential of modern C++ features for EDSL design has been less explored in music, despite the language's capabilities for combining expressive syntax with compile-time guarantees.

## 2.4. Gap Analysis

The review of existing systems reveals several gaps that the Gesture Composition Framework addresses:

1. **Integration of Gesture Concept:** While the importance of gesture is recognized in music research, existing tools do not fully integrate it as the fundamental organizing principle for composition.

2. **Compile-time Safety:** Most music programming environments defer validation to runtime, missing opportunities for early error detection that modern C++ can provide.

3. **Rich Parameter Evolution:** Existing systems support parameter automation but lack integrated tools for defining complex, interdependent parameter trajectories as unified musical gestures.

4. **Balance Between Expression and Rigor:** Current tools tend to favor either intuitive expression (at the cost of technical rigor) or technical precision (at the cost of intuitive expression), with few successfully balancing both aspects.

5. **Temporal Structuring:** Complex temporal structures like *accelerando* or *precipitando* often require verbose implementations, lacking concise abstractions for these common musical patterns.

The Gesture Composition Framework addresses these gaps by treating gesture as the atomic unit of musical expression, leveraging C++ concepts for compile-time validation, providing rich parameter evolution capabilities, and embedding a domain-specific language that balances expressive power with technical rigor.

# 3. CONCEPTUAL FRAMEWORK

## 3.1. Core Components

### 3.1.1. *Gesture as the Atomic Unit*

At the heart of the Gesture Composition Framework (GCF) lies the concept of gesture as the fundamental unit of musical expression. Unlike traditional approaches that focus on individual samples or pure synthesis parameters, a gesture in the GCF represents a complete musical idea with temporal evolution. Gesture defining features include:

1. Duration

2. Start Time

3. **Parameters:** A set of evolving values that define the gesture's characteristics.

4. **Processable:** A reference to the sound-producing constrained class that realizes the gesture.

5. **Pattern:** An optional rhythmic or structural pattern that shapes the gesture.

<footnote n="2">²Haskell is a purely functional programming language known for its strong static typing and elegant handling of abstractions.</footnote>
This approach aligns with how composers naturally think
about musical ideas, allowing for a more intuitive mapping be-
tween musical intention and computational representation.

The current implementation of GCF focuses on mono-channel
audio output, with spatial distribution capabilities planned for
future development (see Section 6.2.1). This initial constraint
allows for a focused exploration of temporal and parameter evo-
lution aspects of gestures before extending to spatial dimensions.

3.1.2. Parameter Evolution

Parameters in the GCF are not static values but evolving trajec-
tories. This evolution can follow various patterns, including:

**Constant** Maintaining a single value throughout the gesture

**Linear** Smoothly transitioning between start and end values

**Quadratic** Following a quadratic curve for more dynamic evolution

**Custom** User-defined functions for complex parameter trajectories

This rich representation of parameter evolution allows com-
posers to create dynamic, expressive gestures that evolve natu-
rally over time.

3.1.3. Processable Concept

The GCF uses C++ concepts<fnref n="3" /> to define the constraints for sound-
producing classes (instruments). Any class that satisfies the Pro-
cessable concept can be used as an instrument in the framework.
This design decision deliberately favors generic programming
based on templates and concepts rather than adopting an object-
oriented approach, even with static polymorphism. This choice
prioritizes compile-time safety and optimization opportunities
while avoiding the runtime overhead and complexity of virtual
method dispatch, resulting in both more expressive code and bet-
ter performance. This approach provides:

1. Type Safety: Compile-time validation of instrument compatibility.

2. Extensibility: Easy integration of new instrument types.

3. Clarity: Clear requirements for instrument implementation.

The *Processable* concept requires:

* A static `getParameters()` method that returns parameter constraints.

* A `process()` method that produces audio samples based on current parameters.

This approach allows for a flexible, yet type-safe, integration
of various sound synthesis techniques.

3.1.4. Pattern Structure

The *Pattern* component provides a way to structure gestures ac-
cording to rhythmic or structural patterns. Patterns consist of:

**Sound Elements** Periods where the instrument is active.

**Silence Elements** Periods where the instrument is inactive.

**Time Unit** A scaling factor for the pattern elements.

**Transformation Rules** Functions that can modify the pattern over time.

This pattern structure allows for complex rhythmic gestures like *accelerando*, *ritardando*, or *precipitando*, which are challenging to implement in traditional computer music frameworks.

3.1.5. Score and Director

The *Score* component serves as a container for multiple gestures, allowing for:

* Sequential or overlapping arrangement of gestures.

* Validation of gesture relationships.

* Retrieval of gestures in time order.

The *Director* component handles the rendering of scores to
audio files by:

* Orchestrating the execution of gestures.

* Mixing overlapping gestures.

* Managing the overall rendering process.

3.2. Component Interactions

Figure 1 illustrates the relationships between GCF's core com-
ponents. The interactions form a cohesive system for expressing
musical ideas through:

* **Gesture Creation:** Composers define gestures using the EDSL, specifying duration, parameters, and patterns.

* **Parameter Evolution:** Parameter components manage value trajectories over time.

* **Instrument Processing:** Processable-compliant instruments respond to parameter changes, producing audio.

* **Pattern Application:** Pattern components structure gestures' temporal aspects.

* **Score Assembly & Rendering:** Score organizes gestures into compositions, while Director renders to audio.

This architecture enables direct expression of musical concepts as computational entities while maintaining type safety and compositional flexibility.

3.3. Design Principles

The design of GCF's conceptual framework follows several key
principles that distinguish it as a computer-based composition
framework:

**Gesture-Centric Organization** The framework treats gestures as the fundamental unit of musical expression, encapsulating both temporal evolution and parameter relationships within a single conceptual entity. This approach matches how composers can conceptualize musical ideas while providing computational precision.

**Temporal Abstraction** GCF abstracts the representation of time-based musical relationships through pattern structures and parameter evolution trajectories. This allows composers to express complex temporal concepts (*accelerando*, *precipitando*, gradual parameter changes) as unified compositional elements rather than sequences of discrete events.

**Type-Safe Composition** Through C++ concepts and template metaprogramming, the framework ensures compositional validity at compile time. This provides immediate feedback about structural inconsistencies and parameter mismatches, reducing the debugging overhead common in computer music programming.

**Modular Flexibility** The separation between gestures (compositional units) and instruments (sound-producing entities) allows composers to focus on musical structure independently of specific synthesis techniques, while maintaining the flexibility to integrate various sound generation approaches.

These principles collectively address the challenge of maintain-
ing conceptual clarity while working within computational con-
straints, enabling composers to focus on musical decisions rather
than implementation details.

<footnote n="3">³A Concept is a named set of requirements for template parameters introduced in C++20. Concepts allow for more expressive template constraints, clearer error messages, and better IDE support compared to traditional SFINAE techniques. They provide compile-time validation of template parameters, ensuring that only types meeting specific requirements can be used with a given template.</footnote>
<figure><img src="image_4.png" /><figcaption>Figure 1: GCF Component Diagram illustrating relationships between core framework components</figcaption></figure>
# 4. EDSL DESIGN

The Gesture Composition Framework (GCF) features a carefully designed Embedded Domain-Specific Language (EDSL) that bridges the gap between musical thinking and computational implementation. This section explores the design and implementation of the EDSL, highlighting how it enables intuitive and expressive musical composition while maintaining the type safety and performance benefits of C++.

## 4.1. Design Goals and Language Specifications

The development of the GCF’s EDSL was guided by several key design goals:

1. Readability: The syntax should be clear and intuitive, reflecting how some composers think about musical gestures.

2. Type Safety: The EDSL should leverage C++'s type system to catch errors at compile time.

3. Expressivity: The language should allow for complex musical expressions without becoming verbose or convoluted.

4. Extensibility: The design should be open to extension without requiring changes to the core framework.

5. Error Handling: Error messages should be clear and point directly to the origin of the problem.

## 4.2. Syntax Evolution

The EDSL syntax evolved through multiple iterations, with various approaches considered and evaluated. The final design adopts a method chaining approach with a builder pattern<fnref n="4" />, which offers an intuitive and flexible syntax while maintaining type safety.

```cpp
const auto gesture = Gesture<SinOsc>()
    .starting(0) // Start time in seconds
    .lasting(2) // Duration in seconds
    .having("amplitude", 0.7) // Constant
        amplitude
    .having("frequency", 440, 880, EvolutionType
        ::Linear) // Frequency sweep
    .create();
```

This proposed syntax can allow composers to express musical ideas in a way that closely mirrors how they think about gestures, with clear specification of start time, duration, and evolving parameters.

## 4.3. Builder Pattern Implementation

The EDSL is implemented using a builder pattern, which provides a fluent interface through method chaining while enabling incremental construction, state tracking, and deferred creation. The core implementation is the GestureBuilder class template:

```cpp
template <Processable InstrumentT>
class GestureBuilder {
public:
    GestureBuilder &starting( double time );
    GestureBuilder &lasting( double duration );
    GestureBuilder &having( std::string_view name
        . double start, double end = 0.0,
        EvolutionType type = EvolutionType::
            Constant);
    GestureBuilder &pattern( Pattern p );
    [[ nodiscard ]] std::unique_ptr< GestureImpl<
        InstrumentT >> create();
private:
    // State tracking and validation
};
```

This builder approach allows for clear error messages when required properties are missing or constraints are violated.

## 4.4. Parameter Evolution

A key feature of the EDSL is its support for parameter evolution, allowing parameters to change over time according to various trajectories:

* `having("amplitude", 0.5, 1.0, EvolutionType::Linear) // Linear fade-in`

* `having("frequency", 440, 880, EvolutionType::Quadratic) // Quadratic sweep`

The implementation resembles the Strategy pattern to represent different evolution types:

```cpp
class Evolution {
public:
    Evolution( double start, double end,
        EvolutionType type )
        : start_(start), end_(end), type_(type) {}
    double evaluateAt( double normalizedTime )
        const {
            // Evaluate parameter at the given
            normalized time
            // according to evolution type (Constant
            , Linear, etc.)
            // ...
        }
private:
    double start_, end;
    EvolutionType type_;
};
```

This approach allows for easy extension with new evolution types while maintaining a consistent interface.

## 4.5. Pattern Specification

The EDSL extends to pattern specification, allowing for complex rhythmic structures:

```cpp
auto pattern = make_pattern({ sound(1),
    silence(1) })
    .time_unit(0.25)
    .transform(
        []( const PatternElement& elem, int iteration) {
            // Transform sound and silence durations
            based on iteration
            // Create accelerating/precipitando effect
            // ...
        },
        until_duration_below(0.1));
```

This pattern syntax allows for the specification of complex patterns like precipitando, where silence durations progressively decrease.

## 4.6. Compile-Time Validation

The EDSL leverages C++ concepts to provide compile-time validation of instruments and parameters:

```cpp
template < Mooptype T>
concept Processable = requires( T t ) {
    T::getParameters() } -> std::
        convertible_to < std::map< std::string,
            ParameterInfo >>;
    t .process( std::vector< Parameter >{}, double
        { }) } -> std::convertible_to < double >;
};
```

This approach catches errors at compile time, providing clear error messages and preventing runtime failures.

## 4.7. Advanced Features

The EDSL includes several advanced features that enhance its expressivity:

* Custom Parameter Functions:

<footnote n="4">⁴The Builder Pattern is a creational design pattern that separates the construction of complex objects from their representation, enabling the same construction process to produce different representations.</footnote>
`.having("frequency", [](double t) { return 440 + 440 * std::sin(2 * M_PI * t); })`

* Pattern Duration Inference:

`.lasting pattern_duration)`

* Pattern Transformations:

`.transform (transformFunction, terminationCondition)`

These capabilities allow complex gesture expressions while maintaining a consistent interface.

## 4.8. Language Features Summary

The EDSL design incorporates several language features specifically chosen to support gesture-based composition:

**Template-Based Flexibility** The use of C++ templates enables type-safe composition while maintaining flexibility in parameter types and value ranges. This allows the same gestural concepts to work with different numerical precisions and parameter scales without sacrificing compile-time validation.

**Concept-Driven Validation** C++ concepts ensure that only valid combinations of gestures, patterns, and instruments can be compiled, moving error detection from runtime to compile time. This approach reduces debugging complexity and provides immediate feedback about compositional structure.

**Functional Composition Operators** The framework provides operators that enable functional composition of gestures and patterns, allowing composers to build complex temporal structures from simpler components. This compositional approach mirrors musical thinking about structural relationships.

**Memory Management Integration** Automatic resource management through RAII and smart pointers ensures that composers can focus on musical structure without manual memory management concerns, reducing technical overhead in the composition process.

These language features collectively create an environment where musical concepts can be expressed directly in code while maintaining the precision and performance characteristics required for computer-based composition.

## 4.9. Embedded DSL for Gesture-Centric Composition

By combining a fluent, intuitive syntax with strong type safety and compile-time validation, the EDSL enables composers to express complex musical ideas clearly and concisely. The gesture-centric approach, combined with rich parameter evolution and pattern specification, provides expressive framework for computer-based music composition.

# 5. QUANTITATIVE ANALYSIS OF GESTURAL EXPRESSIVENESS

This section provides a quantitative evaluation of GCF's gestural expressiveness through the Conceptual Mapping Ratio (CMR) methodology and analysis of type safety benefits.

## 5.1. Conceptual Mapping Ratio (CMR) Methodology

To objectively assess GCF's expressiveness, we introduce the Conceptual Mapping Ratio (CMR), defined as:

**CMR = Musical Concepts / Implementation Elements**

Where higher CMR values indicate more efficient expression of musical ideas relative to implementation complexity.

### 5.1.1. Musical Concepts Definition

**Musical concepts** represent distinct musical ideas that a composer conceptualizes when creating a gesture, independent of implementation details. These include:

1. Temporal Organization: Start time and duration specifications

2. Parameter Definitions: Distinct musical parameters (frequency, amplitude, etc.)

3. Evolution Behaviors: Temporal trajectories for dynamic parameters

4. Instrumental Choice: Selection of sound-producing entities

### 5.1.2. Implementation Elements Definition

**Implementation elements** represent distinct method calls or code constructs required to express musical concepts in GCF:

1. Gesture Construction: Temporal methods (`.starting()`, `.lasting()` and boilerplate method (`.create()`)

2. Parameter Specification: Each `.having()` method call

3. Instrument Selection: Template parameter specification

4. Framework-Specific Constructs: Pattern definitions

### 5.1.3. Methodological Considerations

Our analysis treats temporal evolution as a native framework capability. Since GCF is designed with time as a first-class concept, parameter evolution is considered an intrinsic feature rather than additional implementation burden. This reflects the framework's design philosophy where `.having("amplitude", 0.5, 1.0, EvolutionType::Linear)` represents a single unified operation for temporal parameter control.

## 5.2. Quantitative Analysis Results

We analyze four representative examples that demonstrate different aspects of GCF's gestural capabilities. All examples presented in this analysis are implemented and available as unit tests within the framework repository, ensuring reproducibility and providing practical reference implementations for researchers and composers.

### 5.2.1. Example 1: Simple Sustained Note

```
 Gesture<SinOsc>()
  .starting(0)
  .lasting(2)
  .having("amplitude", mf)
  .having("frequency", 440)
  .create();
```

The gesture requires five distinct musical decisions, while the code implementation consists of six distinct elements.

### 5.2.2. Example 2: Complex Parameter Evolution

```
 Gesture<SinOsc>()
  .starting(0)
  .lasting(2)
  .having("amplitude", 0.5, 1.0, EvolutionType::Linear)
  .having("frequency", 440, 880, EvolutionType::Quadratic)
  .create();
```

The gesture involves five musical decisions, and the implementation requires six code elements.
### 5.2.3. Example 3: Ring Modulation Instrument

```cpp
Gesture<RingModulator>(
  .starting(0)
  .lasting(2)
  .having("carrier.amplitude", 1.0)
  .having("carrier-frequency", 1.0)
  .having("modulator.amplitude", 0.5, 1.0,
    EvolutionType::Linear)
  .having("modulatorfrequency", 440, 880,
    EvolutionType::Quadratic)
  .create();
```

The gesture encompasses seven musical decisions, while the implementation consists of eight code elements.

### 5.2.4. Example 4: Pattern-based Gesture

```cpp
Gesture<ConstantNode>(
  .starting(0)
  .lasting pattern_duration)
  .pattern (make_pattern({sound(1), silence(1)}))
  .time_unit(0.25)
  .transform(emer const PatternElement& elem, int
    iteration) {
    // precipitando logic
  }, until_durationBelow(0.1)))
  .having("amplitude", 0.7)
  .create();
```

The gesture requires eight distinct musical decisions, and the implementation involves eight code elements.

## 5.3. Analysis and Interpretation

The four examples yield CMR values ranging from 0.83 to 1.01.

### 5.3.1. Key Design Achievement: Complexity Invariance

**Critical Observation:** Examples 1 and 2 achieve identical CMR (0.83), demonstrating that GCF maintains constant expressiveness regardless of parameter evolution complexity. This validates the framework's core design goal: making temporal evolution a zero-cost abstraction from the composer's perspective. A composer can transform any static parameter into a sophisticated dynamic evolution without increasing the conceptual-to-implementation burden, proving that temporal behavior is truly a first-class framework feature.

### 5.3.2. Type Safety Benefits

GCF's compile-time validation provides comprehensive error detection. The framework's parameter validation system detects range violations such as negative frequency values or amplitude parameters exceeding 1.0, while simultaneously ensuring that all required parameters for specific instruments are properly specified and that parameter names correspond to valid instrument interfaces. The structural validation capabilities extend beyond individual parameters to encompass the entire gesture architecture, detecting duplicate method calls that would create ambiguous temporal specifications, identifying invalid connections within InstrumentDAG topologies that could lead to signal flow inconsistencies, and performing cycle detection in signal flow graphs to prevent infinite feedback loops that would render the composition inoperable. Temporal validation represents a particularly sophisticated aspect of GCF's compile-time checking, identifying pattern inconsistencies such as empty pattern definitions or invalid time unit specifications, detecting mismatches in evolution parameter configurations that could result in undefined temporal behaviors, and validating duration and timing constraints to ensure temporal coherence across the entire gestural structure.

### 5.3.3. Framework Expressiveness Characteristics

**High Baseline Efficiency** All examples achieve CMR ≥ 0.83, indicating strong expressiveness even with framework overhead.

**Abstraction Benefits** More sophisticated abstractions (patterns, instruments) achieve higher CMR values, demonstrating that complexity encapsulation improves expressiveness.

**Predictable Cognitive Load** Consistent CMR values within example categories suggest predictable learning curves for composers adopting different framework features.

**Scalability** The framework maintains high expressiveness as musical complexity increases, validating its suitability for sophisticated compositional applications.

## 5.4. Discussion

The quantitative analysis reveals several key insights about the gesture-centric approach implemented in GCF compared to traditional synthesis frameworks. These findings have significant implications for both the theoretical understanding of computer music composition and practical tool development.

First, the consistently high Conceptual Mapping Ratio in GCF demonstrates that a gesture-centric approach can effectively bridge the gap between musical intention and computational implementation. This alignment supports the core hypothesis that treating gestures as first-class citizens in the compositional process could lead to more intuitive expression of gestural based musical ideas.

Second, the compile-time safety provided by GCF represents a significant advancement. By leveraging C++ concepts for instrument and parameter validation, GCF shifts error detection from runtime to compile time, potentially eliminating entire categories of compositional errors before they manifest in performance. This safety aspect is particularly valuable in listening sections where runtime errors can be catastrophic.

Third, the consistent interface for parameter evolution in GCF—regardless of trajectory complexity—reduces cognitive load for composers. GCF's uniform methods for specifying linear, quadratic, or custom parameter changes enable composers to focus on the musical outcome rather than implementation details.

The pattern-based example particularly highlights GCF's advantage in expressing complex temporal structures, achieving optimal expressiveness (CMR = 1.0) when dealing with specialized temporal constructs.

It is important to note the context in which GCF was developed. Indeed, GCF provides a middle layer between lower-level C++ and compositional thinking. GCF was initially conceived during the development of Campi Instabili, an author's piece exploring granular synthesis and tetrahedral loudspeaker array<fnref n="5" />. This composition required sample-precision control over phase relationships between grains and their internal content—a level of control that motivated direct C++ implementation rather than existing frameworks. GCF emerged from this experience as a solution for composers who accept the overhead of C++ but desire a more intuitive gesture-centric API without rebuilding basic infrastructure for each new piece. In this niche, GCF would excel by allowing composers to focus on the gestural relationships while simplifying instruments and signal processing through clear parameter interfaces and compositional abstractions. Additionally, the author would re-implement Campi Instabili using GCF, to understand if the framework acts in a transparent way, as intermediate layer between composer and C++, or as a mediation layer, changing how the composer would behave in the absence of the framework.

<footnote n="5">⁵Spherical Tetrahedral One, as known as S.T.One, is an outer radiating tetrahedral loudspeaker array designed and developed by Giuseppe Silvi.</footnote>
<table><caption>Table 1: Comparative CMR for different Examples</caption><thead><tr><td>Example</td><td>CMR</td><td>Insight</td></tr></thead><tbody><tr><td>Simple Sustained Note</td><td>0.83</td><td>Boilerplate overhead in basic cases</td></tr><tr><td>Complex Parameter Evolution</td><td>0.83</td><td>Complexity invariance achieved</td></tr><tr><td>Ring Modulation</td><td>0.88</td><td>Instrument abstraction benefits</td></tr><tr><td>Pattern-based Gesture</td><td>1.0</td><td>Optimal temporal abstraction</td></tr></tbody></table>

These findings suggest that future computer-based composition frameworks might benefit from considering CMR as a leading criterion for framework design and development, prioritizing conceptual alignment.

# 6. CONCLUSION AND FUTURE WORK

## 6.1. Conclusion

The Gesture Composition Framework is presented as an ongoing research project. The current implementation serves as a proof of concept that demonstrates the potential of a gesture-centric approach to computer-based composition framework. Indeed, it represents a significant shift in computer-based composition framework by elevating gestures to first-class citizens. Our quantitative analysis demonstrates that GCF could offer substantial benefits through higher conceptual alignment between musical intention and computational implementation.

The consistently high Conceptual Mapping Ratio across examples confirms our core hypothesis—that a gesture-centric approach effectively bridges the gap between musical thinking and technical implementation. This alignment is further strengthened by GCF’s compile-time safety through C++ concepts, eliminating categories of errors before they manifest in performance.

Additionally, GCF’s consistent CMR values suggest predictable cognitive load, which could result in predictable learning curves for composers adopting the framework.

## 6.2. Future Work

Several promising directions for future development include:

### 6.2.1. Spatial Distribution and Pattern Extensions

Expanding beyond mono-channel audio with gesture-level spatial relationships; enhancing pattern transformation capabilities for complex temporal structures including Markov-based generation and polyrhythmic layering.

### 6.2.2. Gesture Transformation and State Management

Introducing transformational rules to derive new gestures from existing ones, enabling compositional strategies like theme and variations; implementing instrument state management for gestural continuity across compositional sections.

### 6.2.3. Performance Optimization and Integration with Existing Unit Generator Libraries

Adding real-time capabilities through audio API integration and multi-threading optimizations; creating adaptors for established unit generator libraries such as CSound, SuperCollider’s UGens, and the Synthesis ToolKit (STK), and Faust to leverage signal processing capabilities.

## 6.3. Code Availability

The complete source code for the Gesture Composition Framework<fnref n="6" /> is available as an open-source project under the GPL3 license. The repository is hosted on the author’s personal GitLab

instance; readers interested in obtaining an account may contact the author directly.

As an independent researcher who has learned extensively from open-source software, the author considers maintaining this project as open source an essential contribution to the computer music research community. The open-source nature of GCF facilitates reproducibility of research results, enables collaborative development, and supports educational applications in computer music composition.

# 7. ACKNOWLEDGMENTS

I would like to thank Davide Tedesco for the insightful conversations and thorough review, Francesco Roberto Dani for his unwavering support throughout this project, Alessandro Benedetti for his review, and Agostino Di Scipio for his valuable guidance and mentorship. Additionally, I extend my gratitude to the anonymous reviewers whose feedback significantly improved this paper.

# 8. REFERENCES

[1] Miller Puckette et al., “Pure data: another integrated computer music environment,” *Proceedings of the second international computer music concerts*, pp. 37–41, 1996.

[2] Miller Puckette, “Max at seventeen,” *Computer Music Journal*, vol. 26, no. 4, pp. 31–43, 2002.

[3] Barry Vercoe et al., “Csound,” *The CSound Manual Version*, vol. 3, 1986.

[4] James McCartney, “Rethinking the computer music language: Super collider,” *Computer Music Journal*, vol. 26, no. 4, pp. 61–68, 2002.

[5] Paul Lansky, “A view from the bus: when machines make music,” *Perspectives of new music*, pp. 102–110, 1990.

[6] Claude Cadoz and Marcelo Mortensen Wanderley, “Gesture-music,” *Trends in gestural control of music*, 2000.

[7] Carlos Agon, Jean Bresson, and Marco Stroppa, “Omnochrome: Compositional control of sound synthesis,” *Computer Music Journal*, vol. 35, no. 2, pp. 67–83, 2011.

[8] Hans G Kaper, Sever Tipei, and Jeff M Wright, “Dissco: A unified approach to sound synthesis and composition,” in *ICMC*, 2005.

[9] Marije AJ Baalman, “Spatial composition techniques and sound spatialisation technologies,” *Organised Sound*, vol. 15, no. 3, pp. 209–218, 2010.

[10] Ge Wang, Perry R Cook, and Spencer Salazar, “Chuck: A strongly timed computer music language,” *Computer Music Journal*, vol. 39, no. 4, pp. 10–29, 2015.

[11] Andre Rauber Du Bois and Rodrigo Geraldo Ribeiro, “Hmusic: A domain specific language for music programming and live coding.,” in *NIME*, 2019, pp. 381–386.

<footnote n="6">⁶markidis.space/gesture-composition-framework/gcf</footnote>