Possible bugfix: Make Osirus/Ostirus controller dumps address page B by part - #290

Background

REQUEST_CONTROLLER_DUMP (0x37) asks the device to report a part's edit buffer as a burst of individual controller messages rather than as a sysex dump. buildControllerDumpResponse (virusLib/microcontroller.cpp) builds that reply: page A goes out as control change, page B as poly pressure.

Page A carries the part number in the status byte's low nibble. Page B does not — it always goes out on nibble 0, whichever part was requested.

The inconsistency

Three places in microcontroller.cpp decide how a part is addressed in page A/B controller traffic. Two of them agree with each other and the third does not:

The device's own receive path treats the page B nibble as a part index. The dump builder honours that convention on the line for page A and drops it on the line directly below. Nothing in the file explains the asymmetry, and no in-plugin consumer appears to depend on it.

The change

-for (const auto cc : g_pageB)  _responses.emplace_back(MidiEventSource::Device, M_POLYPRESSURE, cc, single[cc + 128], 0);
+for (const auto cc : g_pageB)  _responses.emplace_back(MidiEventSource::Device, M_POLYPRESSURE + channel, cc, single[cc + 128], 0);

channel is the same local the page A line already uses: the requested part, or 0 for the SINGLE slot.

Effect

A controller dump requested for part N now delivers both halves of that part's edit buffer to part N. Before this, page A landed on part N and page B landed on part 0, so a dump for any part other than 0 silently wrote half its payload into the wrong part's parameters.

Requesting a dump for part 0, or for the SINGLE slot in single mode, is unaffected — those already resolve to nibble 0.

Testing

Verified in-situ on live Osirus and OsTIrus instances, against builds with and without this change.

The method relies on a raw sysex reaching the device without refreshing the plugin's parameter cache. A PAGE_B parameter-change message moves a value on the device only, leaving the cache deliberately stale; the controller dump is then the only thing that can resynchronise it, so watching which part catches up reads the addressing decision directly. All parts are seeded with known values first, so a mis-route shows up as the wrong part moving rather than as an ambiguous no-op, and each test asserts the cache did not move before the dump was requested.

The second row is the control: part 0 was already the correct destination there, so a change would have indicated the fix overshot. The page A phases of the same battery are byte-identical with and without this change, confirming it does not disturb the half that was already correct.

Interaction between three related PRs

I have submitted three PRs affecting Osirus/Ostirus MIDI channel handling, and they are easiest to reason about together:

• Possible bugfix: Osirus/Ostirus now apply global MIDI channel selection to MIDI-learned automation #285 - resolve single mode against the global MIDI channel, instead of a hardcoded 0.
• Possible bugfix: Make Osirus/Ostirus controller dumps address page B by part #290 - emit page B of the controller dump with the part in the status byte's low nibble, instead of a hardcoded 0.
• Refactor: Unify Osirus/Ostirus onto the shared controller mapping system #291 - route parameter traffic through the shared controller map, with device-sourced traffic exempt from channel resolution.

The table below considers the effects of various combinations of these three PRs on MIDI handling.

• Behavior 1: In single mode, if the global MIDI channel is set to channel G != channel 0, and a MIDI-learned mapping is bound to channel G, which part does it resolve to? The same resolution also drives program change routing and the parameter overlay indicators.
• Behavior 2: In single mode, if the global MIDI channel is set to channel G != channel 0, and CC is sent to that channel, which part is written?
• Behavior 3: In single mode, if the global MIDI channel is set to channel G != channel 0, and CC is sent to channel 0, which part is written?
• Behavior 4: In multi mode, if a dump of part N != part 0 is requested, which part do the page B parameters get written to?

Two behaviours are correct in every combination and are left out of the table below: the single-mode controller dump, and the page A half of a multi-mode dump.

Row 1 is current behavior, and no row regresses against it, so any subset may be merged in any order. Row 2 is the only one that can look like a regression, since #291 alone drops a control change that is delivered today, but today it is delivered to the wrong part, so neither matches the device.

#290 is independent: it flips Behavior 4 identically in every row. #285 independently fixes Behavior 1. For Behaviors 2 and 3, however, #285 and #291 are complementary rather than independent, and neither alone produces the correct result.

AI Disclosure: This PR was made with the help of an AI coding assistant.