PadForge v3.3.2 is released. Modern controller mapping utility for Windows. Maps any controller, keyboard, or mouse to virtual Xbox 360, DualShock 4, custom DirectInput, or MIDI controllers via ViGEmBus, vJoy, and Windows MIDI Services that games and applications see as real hardware.

PadForge changelog:
Three bug fixes against v3.3.1. Reported on a multi-device setup (arcade sticks + Xinmotek + Xbox Series X across two virtual controllers).
Copy From / Copy / Paste retargets onto the destination slot's device
Previously, copying a slot's mapping table onto another slot kept every Source's DeviceGuid pointing at the source slot's physical-device instance. If both slots had different physical instances of the same product, the destination slot's MappingSet ended up reading the source slot's hardware. Now each Source's DeviceGuid is rewritten onto a target-slot UserSetting whose ProductGuid matches the source device's variation. If the source's own instance is itself assigned to the destination slot, it's kept; otherwise the first different-instance same-product device on the destination is used. Sources whose product isn't on the destination at all are dropped.
Affects both the in-process "Copy From" dialog and the clipboard Copy / Paste flow. Shift activator DeviceGuid + ChordSecondDeviceGuid retarget along the same path.
Extra-source Record button on Y-axis targets agrees with the primary
The two Record buttons on a mapping row (the primary descriptor and the per-source "+ Add Source") were splitting on the Y-axis convention. The primary handler passed negRecording=true for Y-axis targets (so ShouldAutoInvert routed through the axisPositive branch — UP press = non-inverted); the extra-source handler omitted it (so the !axisPositive branch ran — same UP press = inverted). Same row, two record buttons, opposite Invert flags on the same physical input.
WireExtraSource now mirrors the primary handler's isYAxis check. Both record buttons on a Y-axis row record an UP press as non-inverted, a DOWN press as inverted.
Joystick-class devices migrate through the legacy-XML pipeline
BuildOneSlotFromLegacy filtered devices by CapType == Gamepad (21) before passing them to the migrator. Joystick-class devices (CapType 20 — DirectInput arcade sticks, racing wheels, flight sticks, throttles) were excluded from MappingSet construction. A slot with three contributing devices (e.g. UltraStik + Xinmotek + Xbox Series X) came out with only the Gamepad's sources; the user's authored mappings on the joystick devices disappeared.
Predicate widened to the controller-class set (Gamepad + Joystick + Driving + Flight + FirstPerson + Supplemental) — matching what DeviceService.AutoEnableHidingDefaults already used. Mouse / Keyboard / Touchpad still excluded so a keyboard's stale auto-mapped gamepad descriptor can't pollute a migrated row.
To recover a backup that lost devices to the old filter: restore the pre-migration PadForge.xml and relaunch on v3.3.2 — the joystick-class devices will populate the MappingSet on this load.

Download: PadForge v3.3.2
Source: Here