Combination Actions, MIDI, and Console Software

A combination action is the system that stores a registration and recalls it when a piston is pressed, and it takes three working parts to do that. A theater-organ reference, the Cinema Organ Society’s Theatre Organ Fact Finder, separates those parts into a combination memory, the pistons as the signaling means, and a stop action that moves the stops themselves; all three must be present. The piston does not hold the registration; it selects a stored combination that the memory holds and the stop action carries out. An Organ Historical Society text adds that combination pistons are found only on organs with electric stop action.

On a multilevel capture system, a memory level is a complete and independent set of piston memories, so changing the level changes what every piston recalls without altering the settings held on any other level; Solid State Organ Systems’ MUCAP operation guide states this for its own product. Capacity, setting method, and the differences between capture and setter-board designs are explained on the combination-action page.

A sequencer, sometimes labeled a stepper, is a navigation function over combinations that are already stored; it is not a memory technology and it does not itself hold the registrations. Orgues Letourneau describes it as moving through a pre-programmed sequence of general pistons, and Solid State Organ Systems describes a stepper that runs through the generals and moves to a new memory level when needed, together with an advanced sequencer that allows steps to be inserted. A sequencer therefore depends on the combination action beneath it: what it steps through is whatever the memory holds. Across these pages, sequencer always means this registration navigation, and the design differences between sequencers are covered on the combination-action page.

MIDI is a protocol for control data, not a source of sound. The MIDI Association, which maintains the specification, defines it as a means for musical instruments and devices to communicate using digital messages that carry musical performance and device-control data such as notes, program changes, and expression control; the original 1983 specification defined a core data format and a serial transport on five-pin DIN connectors. On a pipe organ, that means a MIDI system deals in control events, such as which note has been sounded or which program change or expression value has been sent, and not in audio. How a console’s own switching is converted into that data, and back again, is the subject of the MIDI page.

Record and playback captures a performance as control data and reproduces it, which is a separate capability from MIDI itself even though, in the documented examples, that data travels in MIDI form. Peterson, for example, describes its ICS-4000 as recording and playing back key, stop, and expression data in standard MIDI format without an external device, and Syndyne describes a stand-alone record and playback unit for organ systems that already have MIDI IN and OUT connectors. A console can therefore have MIDI connections and still need a separate unit before it records anything; recording is a function a product may build in, add on, or leave out.

Configuration software is the layer in which a control system’s layout and permissions are set, and in the documented products it belongs to the builder or technician rather than to the organist. Peterson’s manuals record the same division across four product generations: operating the instrument is the organist’s side of the line, and changing what the controls do is assigned to the organ builder or organ technician. Those are Peterson’s documented divisions for its own products; who actually holds configuration access on a given instrument is settled by that instrument’s documentation or its technician, not by the console. The access-boundaries page takes that question up in full.

On a modern electric-action console, pressing a piston, moving a coupler tab, or moving a shoe asserts a request, and a separate switching system, which many people simply call the relay, executes it. That is why the behavior of a control is determined by how the system is configured and not by the control itself: manufacturers’ own descriptions say that the console’s keys, stops, and expressions are read and routed to a processor that drives the chests, that coupling is processed in the control computer rather than by coupler relays, and that a piston’s scope or range is a configurable property independent of its engraved label. Taken together, those descriptions give the general principle, which holds for electric-action control systems and not for mechanical stop and key action.

The combination action and the switching system are therefore separable jobs: the combination action recalls a registration and sets the stop controls to it, and the switching system routes what the keys and the drawn stops ask for to the chests.

The two jobs may be met by separate products in the same console. An earlier Syndyne product line, documented in its 2010 LS2400K Keying System manual and its 2006 CS5608 Combination Action manual, was divided into keying systems and combination actions as distinct board families, and the single-board combination action is described as a complete setter-style combination action suitable for small to moderate two-manual organs. That division is a design choice rather than a necessary boundary, because other systems, Peterson’s ICS-4000 among them, integrate keying and combination action in a single product.

One product can provide several of these jobs at once, and when it does, the product’s own documentation is the authority on what it includes. As of September 2026, Peterson describes the ICS-4000 on its own website as combining coupling, unification, combination action, and MIDI functions in a single software-driven system using distributed processing over Ethernet, with memory levels organized in per-organist folders under password protection, recording and playback of key, stop, and expression data in standard MIDI format without an external device, a transposer, and a piston sequencer in American and European modes. Those are Peterson’s statements about its own product and generation, and its specifications are subject to change without notice; they establish nothing about what other products do or whether any particular instrument can be so equipped.

The same jobs can also be supplied as separate products, and the separation shows in the suppliers’ own catalogs. Peterson’s product catalog lists the ICS-4000 Integrated Control System alongside a Duo Set Combination Action, Diode Matrix Switching, an OrgaPlex Switching/Coupler, a Solid State Chime Relay, a MIDI Resource System, and the RC-150 Electronic Swell Shade Operator; a catalog index shows how a supplier divides its products, not what is installed in any instrument.

Record and playback is the clearest example of a job that can stand alone: Syndyne describes a stand-alone MIDI record and playback unit that can be added to an already-converted console without replacing its control system, usable with most organ systems that have MIDI IN and OUT connectors. That condition matters, because an older solid-state relay may not have MIDI IN and OUT, and a console that was never converted would not qualify at all. Whether your console has one integrated system or several separate products changes what to look for and whom to ask, and it is worth establishing before reading any of the three focused pages.

An organist at an unfamiliar console cannot tell from the visible controls alone how many memory levels exist, which pistons are ranged to which stops, whether the combination action is locked, or whether a sequencer is enabled. Each of those limits follows from something documented for a named system: piston scope is configurable and independent of the engraved label, combination actions may be locked, memory levels may be gated by a PIN or a folder, and a sequencer piston is inert until the sequencer is enabled. Taken together, they mean the console’s surface does not disclose its configuration, and the remedy is the instrument’s own documentation or its technician, not experimentation at someone else’s console.

That limit is also why this territory needs three focused pages rather than one: what a combination action can hold, what MIDI carries, and who may change configuration are each questions that documentation answers and the console panel does not. When that documentation is missing, establishing what a control system actually does becomes an inspection and documentation task rather than something to work out by trial at the console.