Someone brought up a point of confusion of how the rules of polyphonic modules are defined, so I’d like to clarify the motivation behind the polyphony standard.
If a monophonic signal is patched into a polyphonic module currently running with N engines (each representing a polyphonic channel), the monophonic signal is copied to all engines.
If you’re familiar with programming, you can think of monophonic signals as “scalars” that implicitly cast to polyphonic signals (vectors) when incompatible types interact. For example, the expression a + [b1, b2, b3] should reduce to [a + b1, a + b2, a + b3].
If you’re familiar with mathematics, a monophonic signal is a rank-0 tensor (over time) while a polyphonic signal is a rank-1 tensor (over time). An operation like summing would look like (a + \vec{b})_i := a + b_i. (Note that in this analogy, rank-1 tensors with dimension 1 cannot be represented in Rack.)
The user-benefiting motivation is to be able to use the same input port (e.g. FM input) rather than two different ports (e.g. mono FM and poly FM inputs) in order to either modulate each polyphonic engine (e.g. VCO) with a same-channel polyphonic signal or to modulate all polyphonic engines with a 1-channel monophonic signal.
The standard says
The number of active engines N should be defined by the number of channels of the “primary” input
However, it is purposefully vague in specifying what a “primary” input is. In some cases, there is no primary input at all because all inputs must be treated with equal respect. Martin Lueders and I discussed that when polyphon-izing Befaco A*B+C (where neither A, B, nor C are the “primary” input), the number of engines should be computed by max(#A, #B, #C) where #x is the number of channels of input x. This allows you to mix-and-match mono and poly cables in the A, B, and C inputs, so the result is a polyphonic signal that correctly controls the rest of your polyphonic patch.
Just some thoughts if you’re developing a module that supports polyphony.
, use 
