Processing Expression

When you write x * x, you’re not “squaring numbers.” You’re defining a transfer curve:

• Input -1.0 → Output 1.0
• Input 0.5 → Output 0.25 (quieter)
• Input 1.0 → Output 1.0 (same)

This asymmetry adds harmonics. The waveform’s shape bends: its geometry changes.

Analog distortion (tubes, tape) works this way: input voltage doesn’t map linearly to output. The circuit’s response curve adds character.

Polynomials let you design that curve digitally. x * x is gentle. x * x * x adds different harmonics (odd instead of even). std::tanh(x) mimics tube saturation.

You’re sculpting frequency response through function shape.

vega.Polynomial([](double x) { return x * x; }) creates a Polynomial node, a mathematical expression that processes one sample at a time.

By itself, the node doesn’t touch your audio. You wrap it in a PolynomialProcessor:

auto processor = MayaFlux::create_processor<PolynomialProcessor>(buffers[0], poly);

Why this separation?

• Node: The math itself (reusable, chainable, inspectable)
• Processor: The attachment mechanism that knows how to apply the node to a buffer

Same node, different processors → different results. You’ll see this pattern everywhere in MayaFlux.

The node is the idea. The processor is the application.

Polynomials have three modes:

• DIRECT: f(x) where x is the current sample
• RECURSIVE: f(y[n-1], y[n-2], ...) where output depends on previous outputs
• FEEDFORWARD: f(x[n], x[n-1], ...) where output depends on input history

In DIRECT mode (what you’re using now), each sample is transformed independently. This is memoryless waveshaping.

Later sections explore time-aware modes. RECURSIVE creates filters and feedback. FEEDFORWARD creates delay-based effects.

For now: DIRECT mode = instant transformation. No memory. No delay.

When you call:

auto processor = MayaFlux::create_processor<PolynomialProcessor>(buffers[0], poly);

MayaFlux does this:

1. Creates a PolynomialProcessor wrapping your polynomial node
2. Gets buffers[0]’s processing chain
3. Adds the processor to that chain
4. Returns the processor handle

The buffer now runs your polynomial on every cycle:

• 512 samples arrive from the Container
• Your polynomial processes each sample: y = x * x
• Transformed samples continue to speakers

The processor is now part of the buffer’s flow. It runs automatically every cycle until removed.

// Cubic distortion (more aggressive, odd harmonics)
auto poly = vega.Polynomial([](double x) { return x * x * x; });

// Chebyshev waveshaping (precise harmonic control)
auto poly = vega.Polynomial([](double x) { return 2*x*x - 1; });

// Soft clipping (analog-style limiting)
auto poly = vega.Polynomial([](double x) {
    return x / (1.0 + std::abs(x));
});

// Extreme fold-back distortion
auto poly = vega.Polynomial([](double x) {
    return std::sin(x * 5.0);
});

Listen to each. Same structure, different curves. Each curve generates different harmonic content.

Think of it not as “processing audio” but as sculpting the transfer function.

Classic IIR filter equation:

y[n] = b0*x[n] + a1*y[n-1] + a2*y[n-2]

Your recursive polynomial is that filter, just written as a lambda:

[](std::span<double> history) {
    return 0.5 * history[0] + 0.3 * history[1];
}

Difference: You can write nonlinear feedback:

[](std::span<double> history) {
    return history[0] * std::sin(history[1]);  // nonlinear!
}

Traditional DSP libraries can’t do this. Fixed coefficients only.

Polynomials let you design arbitrary recursive functions, not just linear filters.

When you write:

PolynomialMode::RECURSIVE, 2

The polynomial maintains a buffer of previous outputs:

history[0] = y[n-1]  (last output)
history[1] = y[n-2]  (two samples ago)

Each cycle:

1. Your lambda reads from history
2. Computes new output
3. Polynomial pushes output into history (shifts everything down)
4. Loop repeats

The buffer size determines how far back you can look. Larger buffers = longer memory.

For a 100-sample buffer at 48 kHz:

100 samples ÷ 48000 Hz ≈ 2 ms of history

This is how you build delays, reverbs, resonant filters, and anything else that needs temporal memory.

Critical rule: Keep feedback coefficients summing to < 1.0 for guaranteed stability.

Safe:

return 0.6*history[0] + 0.3*history[1];  // sum = 0.9 < 1.0

Dangerous:

return 1.2*history[0];  // WILL EXPLODE (unbounded growth)

Why? Each cycle multiplies previous output by 1.2. Exponential growth. Your speakers won’t thank you.

MayaFlux won’t stop you. This is a creative tool, not a safety guard. Instability can be interesting (briefly). Controlled feedback explosion creates chaotic textures.

But for stable filters: keep gain < 1.0.

Recursive polynomials need starting values. Default: [0.0, 0.0, ...]

You can seed them:

recursive->set_initial_conditions({0.5, -0.3, 0.1});

Why?

1. Impulse responses: Inject energy without external input. The filter “pings” on its own.
2. Self-oscillation: Non-zero initial conditions + feedback gain ≥ 1.0 = continuous tone.
3. Warm start: Resume from previous state instead of cold-starting at zero.

Example (resonant ping):

auto resonator = vega.Polynomial(
    [](std::span<double> history) {
        return 0.99 * history[0] - 0.5 * history[1];
    },
    PolynomialMode::RECURSIVE,
    2
);
resonator->set_initial_conditions({1.0, 0.0});  // kick-start the resonance

LogicProcessor makes binary decisions about audio.

Every sample asks: “Is this value TRUE or FALSE?” (based on threshold)

Output: 0.0 or 1.0.

Uses:

• Gate: Silence audio below threshold (noise reduction)
• Trigger: Fire events when signal crosses boundary (drums, envelopes)
• Rhythm: Convert continuous modulation into discrete beats

Example: Feed a slow LFO (0.5 Hz sine) into logic → square wave clock.

Digital doesn’t care what the input “means”, only whether it passes the test.

Logic nodes need an input signal to evaluate. This is also true for other nodes like Polynomial.

So far, you did not have to manually set inputs because you used SoundContainerBuffer which automatically feeds audio into processors.

So, instead of creating an AudioBuffer, you can load a file:

auto sound = vega.read_audio("path/to/file.wav") | Audio;
auto buffers = get_io_manager::get_audio_buffers(sound);
auto logic = vega.Logic(LogicOperator::THRESHOLD, 0.0);

auto processor = MayaFlux::create_processor<LogicProcessor>(
    buffer[0],
    logic
);

processor->set_modulation_type(LogicProcessor::ModulationType::REPLACE);

The audio from the file is automatically fed into the logic node. Considering how all previous examples relied on file contents, and the natutre of rhythmic pulses not exploiting the intricacies or richness of audio files, we are using a sine wave as inputs of the logic node in the main example.

LogicOperator defines the test:

• THRESHOLD: x > threshold → 1.0, else 0.0
• HYSTERESIS: Two thresholds (open/close) to avoid flutter
• EDGE: Trigger on transitions (0→1 or 1→0)
• AND/OR/XOR/NOT: Boolean algebra on current vs. previous sample
• CUSTOM: Your function

Right now you’re using THRESHOLD, the simplest test.

Example (hysteresis gate for noisy signals):

auto gate = vega.Logic(LogicOperator::HYSTERESIS);
gate->set_hysteresis_thresholds(0.1, 0.3);  // open at 0.3, close at 0.1

Signal must exceed 0.3 to open, then drops below 0.1 to close. Prevents rapid on/off flickering.

ModulationType provides readymade ways to apply binary logic to audio:

Basic Operations:

• REPLACE: Audio becomes 0.0 or 1.0 (bit reduction)
• MULTIPLY: Audio × logic (standard gate - preserves timbre)
• ADD: Audio + logic (adds impulse on logic high)

Creative Operations:

• INVERT_ON_TRUE: Phase flip when logic high (ring mod effect)
• HOLD_ON_FALSE: Freeze audio when logic low (granular stutter)
• ZERO_ON_FALSE: Hard silence when logic low (noise gate)
• CROSSFADE: Smooth fade based on logic (dynamic blending)
• THRESHOLD_REMAP: Binary amplitude switch (tremolo from logic)
• SAMPLE_AND_HOLD: Freeze on logic changes (glitch/stutter)
• CUSTOM: Your function

Example (granular freeze effect):

processor->set_modulation_type(
    LogicProcessor::ModulationType::HOLD_ON_FALSE
);
// Audio freezes whenever logic goes low - creates stuttering repeats

Example (amplitude tremolo):

processor->set_modulation_type(
    LogicProcessor::ModulationType::THRESHOLD_REMAP
);
processor->set_threshold_remap_values(1.0, 0.2);
// Creates rhythmic volume changes based on logic pattern

Logic becomes a compositional control for transforming audio in musical ways.

You just built a transformation pipeline:

bitcrush → freeze → destroy

Each processor transforms the output of the previous one. This is compositional signal processing: you build complex effects by chaining simple operations.

The power comes from order dependency:

gate → distort    // Clean transients, heavy saturation
distort → gate    // Distorted everything, then choppy

Swap the order = completely different sound.

Extend it:

detect transients → sample-and-hold → bitcrush → wavefold → compress

Traditional plugins give you “distortion with 3 knobs.” You compose the distortion algorithm itself.

Every processor is a building block. Chain them to create effects that don’t exist as plugins:

• Bitcrush → Freeze → Invert = Glitch stutterer
• Remap → Fold → Gate = Rhythmic harmonizer
• Threshold → Hold → Distort = Transient emphasizer

Logic + Polynomial + Chains = programmable audio transformation system.

Swap the order of logic and polynomial → different result:

Logic → Polynomial  // Detect, then distort
Polynomial → Logic  // Distort, then detect

Processors are non-commutative. Audio math doesn’t follow algebra rules.

Order determines signal flow. You’re building a graph, not an equation.

Previously, when you wrote:

auto processor =
    MayaFlux::create_processor<PolynomialProcessor>(buffer, poly);

MayaFlux did this behind the scenes:

1. Created the processor
2. Got the buffer’s existing processing chain
3. Automatically added the processor to that chain
4. Returned the processor

You didn’t see this because it was implicit. The processor was silently appended to whatever chain existed.

Now you’re building chains explicitly:

auto chain = MayaFlux::create_processing_chain();  // Empty chain
chain->add_processor(proc1);  // Manual control
chain->add_processor(proc2);
buffer->set_processing_chain(chain);  // Replace buffer's chain

When to use explicit chains:

• You need precise order control
• You’re building reusable processor “presets”
• You want to swap entire chains dynamically (e.g., switch between clean/distorted modes)
• You’re debugging processor interactions

When implicit is fine:

• Simple cases (1-2 processors)
• Order doesn’t matter (parallel-like effects)
• Rapid prototyping

Chains execute like a for-loop over processors:

for (auto& processor : chain->get_processors()) {
    processor->process(buffer);
}

Data flows sequentially:

Container → Buffer (512 samples)
    ↓
Processor₁: Distortion (modifies samples in-place)
    ↓
Processor₂: Gate (zeroes out quiet samples)
    ↓
Processor₃: Compression (reduces peaks)
    ↓
Speakers

Each processor sees the output of the previous processor.

This is not parallel processing. No branches. No simultaneous paths. Pure sequential transformation.

(Parallel routing requires BufferPipeline, which is covered in a later tutorial.)

Every buffer has two processing stages:

Stage 1: Default Processor (runs first, always)

• Defined by buffer type
• Handles data acquisition or generation
• Examples:
  • SoundContainerBuffer: reads from file/stream
  • NodeBuffer: evaluates a node
  • FeedbackBuffer: mixes current + previous buffer
  • AudioBuffer: none (generic accumulator)

Stage 2: Processing Chain (runs second)

• Your custom processors
• Handles data transformation
• Examples: filters, waveshaping, logic, etc.

Execution flow:

1. Buffer's default processor runs (fills buffer with data)
2. Processing chain runs (transforms that data)
3. Result goes to speakers

When you add processors via create_processor(), they go into Stage 2 (the chain).

The default processor is fixed per buffer type. You can replace it, but usually you don’t need to. The chain is where creativity happens.

You now understand:

Buffer Types:

• AudioBuffer: Generic accumulator
• SoundContainerBuffer: Reads from files/streams (default: SoundStreamReader)
• NodeBuffer: Generates from nodes (default: NodeSourceProcessor)
• FeedbackBuffer: Recursive delay (default: FeedbackProcessor)

Processor Types:

• PolynomialProcessor: Waveshaping, filters, recursive math
• LogicProcessor: Decisions, gates, triggers
• SoundStreamWriter: Capture to containers

Processing Flow:

Default Processor (acquire/generate data)
    ↓
Processing Chain (transform data)
    ↓
Output (speakers/containers/other buffers)

Next: Buffer routing, cloning, and supply mechanics: how to send processed buffers to multiple channels and domains.

You now understand:

Input Capture:

• InputAudioBuffer: Hardware input hub
• InputAccessProcessor: Dispatches to listeners
• create_input_listener_buffer(): Quick setup
• read_from_audio_input() / detach_from_audio_input(): Manual control

Buffer Supply:

• supply_buffer_to_channel(): Route one buffer to multiple outputs
• Mix levels: Control send amounts
• Efficiency: Process once, output many times
• remove_supplied_buffer_from_channel(): Dynamic routing changes

Buffer Cloning:

• clone_buffer_to_channels(): Create independent copies
• Preserves structure: Type, processors, chains
• Independent state: Each clone processes separately
• Post-clone modification: Differentiate behavior after creation

Mental Model:

Input (Microphone)
    ↓
InputAudioBuffer → Listener buffers (capture)
    ↓
Processing chains (transform)
    ↓
Supply (route to multiple channels)
    OR
Clone (create independent instances)
    ↓
RootAudioBuffer (mix per channel)
    ↓
Output (Speakers)

Next: BufferPipeline (declarative multi-stage workflows with temporal control)