Reply to thread

Message: [QUOTE="Bombastus, post: 91138, member: 2178"] Divisimate 2.1 lets Transformer rows process MIDI serially, so each row can receive the altered output produced by the row above it. The existing parallel mode remains available for operations that should inspect the original input independently. That difference changes the meaning of row order. In parallel mode, moving a row may make the interface easier to read, but one transformation does not become the next row's source. In serial mode, dragging the same row can change the MIDI that reaches every operation below it. The Transformer can use notes, note ranges, CC messages, Program Changes, channel pressure, and pitch bend as inputs. Its output choices vary with the selected input, and a row can remap, block, or otherwise alter matching messages. [B]An ordered MIDI processing chain[/B] becomes possible only when each required intermediate message reaches the next operation. [HEADING=2]Parallel rows preserve independent decisions[/HEADING] Choose parallel processing when several rules should examine the controller's untouched MIDI. Every active row receives the original input rather than the output of another row. One row therefore cannot create a new value and expect a later parallel row to recognize that result. This behavior suits independent remaps that happen alongside one another. A pitch-bend rule need not wait for a separate channel-pressure rule, and their positions do not define a processing sequence. The rows remain logically separate even when they sit next to each other. Parallel mode also gives you a useful diagnostic baseline. If a preset works in parallel but changes in serial, the fault probably lies between rows rather than in the first input condition. Check which earlier operation is changing or consuming the message expected farther down. The original message does not always continue beside its transformed version. NextMIDI's documentation says transformed values normally stop passing through in their original form. That prevents a remapped controller or note from automatically reaching the destination twice unless another rule or routing choice creates the duplication. [HEADING=2]Serial rows turn position into a rule[/HEADING] Serial mode passes the transformed output of one row into the next. A controller can become a note in the first operation, then enter a Note Range operation that locks it to Divisimate's global scale. That controller-to-note chain is one concrete use of [B][URL='https://goldmidi.com/community/threads/nextmidi-added-key-splits-to-divisimate-2-1.76472/']Divisimate 2.1's expanded Transformer processing[/URL][/B]. Reverse those operations and the plan fails. The scale operation receives controller data before any note exists, so it has nothing relevant to quantize. The later conversion may still create a note, but that note arrives after the scale rule has already been evaluated. Drag-and-drop row reordering is therefore functional editing, not cosmetic cleanup. Read a serial setup from top to bottom and name each intermediate message before moving anything. If row one outputs a note, row two must accept that note or pass it onward before another conversion changes its type. Reversed output ranges add another order-sensitive option. You can invert a controller range so rising input produces falling output, then let a later row process the inverted result. Placing another controller transformation before the inversion changes the values that the reversed mapping receives. Divisimate allows as many as eight Transformer operations, but length is not sophistication. Each extra row introduces another condition, conversion, and possible point where the expected message disappears. Use the shortest chain that produces the intended result, especially in presets you need to diagnose during a session. [HEADING=2]Short tests expose broken chains quickly[/HEADING] Start with one active row and confirm its output before enabling the next. Add operations in processing order, testing after every change, then compare serial and parallel modes when the result becomes unclear. The comparison reveals whether a row needs original MIDI or an intermediate value. Watch message types as carefully as numeric ranges. Once a row converts CC data into notes, later CC rules cannot act, while Note Range rules cannot quantize unchanged controller data. Correct values of the wrong type still produce a dead chain. There is one documented pass-through exception worth testing deliberately. When notes are transformed into non-note messages such as CC or Program Change, the original notes can continue through as well. If you intended the keys to control commands silently, verify the receiving instrument and use an appropriate blocking or routing decision. Test reversed ranges at their low point, high point, and several values between them. Endpoints can look correct while a later transformation compresses, replaces, or blocks the middle of the range. A slow controller sweep exposes those discontinuities more clearly than a few quick movements. Save only after replaying the same MIDI phrase through the completed preset. Consistent input makes row-order comparisons meaningful and reveals changes caused by reordering rather than performance variation. When the output breaks, return to the first row whose result differs, because every serial operation beneath it is working from altered evidence. [/QUOTE]

Name