Ecasound MIDI Controller Conflicts Explained

This article explores how Ecasound manages control conflicts when multiple MIDI continuous controllers target the identical audio processing parameter. It breaks down Ecasound's internal event-handling architecture, details the "last value wins" resolution rule, explains the practical consequences such as parameter fighting, and provides clear methods for properly structuring MIDI control routings.

The "Last Value Wins" Mechanism

Ecasound routes MIDI continuous controllers (CC) to effect parameters and volume controls using controller mappings, typically declared via the -km setup option. When multiple MIDI inputs, channels, or CC numbers are mapped to the exact same parameter, Ecasound does not implement automated arbitration, prioritization, or value averaging.

Instead, Ecasound operates on a strict "last value wins" model. The engine processes incoming MIDI events sequentially as they arrive from the MIDI subsystem (ALSA sequencer or JACK MIDI). Whenever a MIDI CC message matches a mapped parameter, the engine immediately translates the MIDI data (0–127) to the mapped parameter's specified range (min to max) and writes it directly to the target memory address. If another controller sends an update a millisecond later, it overwrites that value unconditionally.

Audio Engine Processing and Buffer Cycles

Ecasound executes audio processing in fixed buffer cycles defined by the system's buffer size. At the beginning of each cycle, the engine polls the MIDI input queue:

  1. Queue Parsing: Ecasound processes all pending MIDI messages in the order they entered the queue.
  2. Sequential Overwrite: If Controller A and Controller B both send updates within the same processing frame, Ecasound applies Controller A's value, followed immediately by Controller B's value.
  3. Execution: The audio engine calculates the buffer's audio frames using solely the final resolved value from that batch.

Because there is no interpolation or merging logic between conflicting controllers within a single buffer frame, whichever MIDI packet was registered last in the queue defines the state of the parameter for that audio block.

Parameter Fighting and Artifacts

When two physical hardware controllers or automation lanes targeting the same parameter are moved at the same time, a conflict known as "parameter fighting" occurs.

Because both controllers flood the queue with high-frequency updates, the target parameter rapidly alternates between the two conflicting levels. In an audio stream, this oscillation causes noticeable artifacts:

  • Zipper Noise: Rapid stepping of amplitude or filter cutoffs.
  • Audio Clicks and Pops: Sudden, discontinuous changes in audio levels between consecutive processing buffers.
  • CPU Spikes: Unnecessary parameter re-calculations within Ladspa plugins or native chain operators.

Best Practices to Prevent Conflicts

Because Ecasound will not automatically resolve or merge multi-controller collisions, you must structure your signal flow to avoid direct overlaps:

  • Use Serial Operators for Additive Control: If you need two separate controllers to affect the same characteristic (such as master level and track trim), do not map both to one volume parameter. Instead, insert two separate gain operators (e.g., -ea:100 followed by another -ea:100) in the same chain and map each controller to its own operator.
  • Filter MIDI via External Routers: Use dedicated utility software such as mididings, ALSA router tools, or JACK patchbays to intercept, block, or remap overlapping CC messages before the MIDI stream enters Ecasound's input port.
  • Isolate MIDI Channels: Ensure each hardware device communicates on dedicated MIDI channels, and explicitly define both the MIDI channel and CC number in Ecasound's -km configuration string to avoid accidental cross-talk.