Joystick Gremlin vs UCR: Which Feeder Should You Use?

Joystick Gremlin and UCR solve the same first problem — vJoy by itself does nothing until a feeder application writes to it — and then diverge sharply in philosophy. Gremlin is built for flight-sim cockpits: merging HOTAS and HOSAS hardware, shaping axes, and layering modes. UCR is built for universal remapping: almost any input, including keyboard and mouse, onto almost any virtual output. Both are free, both feed vJoy, and the right choice depends on what you are feeding and why. One ground rule before the comparison: Joystick Gremlin cannot work without vJoy — it has no driver of its own — so install vJoy first from the download page.

Joystick Gremlin: the sim cockpit feeder

Joystick Gremlin (by WhiteMagic, actively maintained) exists to turn several physical devices into one coherent virtual cockpit. Its signature jobs are merging multiple physical sticks, throttles, and pedals into a single vJoy device; applying response curves so an axis feels right around the centre; building modes that re-map every button per phase of flight; and running macros and Python-scripted logic. Star Citizen HOSAS players and DCS pilots are its home audience, and community mapping packs are usually Gremlin packs. If your problem statement includes the words “merge,” “curve,” or “mode,” Gremlin is speaking your language.

UCR: the universal remapper

UCR — Universal Control Remapper (by Snoothy) — starts from the opposite end: any input should be mappable to the outputs a game will accept. Keyboards, mice, joysticks, racing wheels, and even eye trackers can be remapped through its provider-plugin design. For DirectInput output, UCR’s provider is vJoy; for Xbox-style output, its provider is ViGEm. That breadth makes UCR the natural pick when the input is not a joystick at all — driving a virtual stick with keyboard keys or mouse movement, building accessibility mappings, or prototyping an odd control scheme quickly — jobs Gremlin’s cockpit focus handles awkwardly or not at all.

Pick by use caseGremlinUCR
Merge two sticks + throttle into one virtual device✔ Best fitPossible, less specialised
Per-axis response curves & modes✔ Core strengthBasic by comparison
Keyboard / mouse → virtual joystickNot its job✔ Core strength
Accessibility & unusual input devicesLimited✔ Provider breadth
Sim community packs & shared profiles✔ (DCS, Star Citizen)Smaller library
Xbox (ViGEm) output as well as vJoyNo✔ Both providers
PriceFreeFree

How to choose in practice

  • Choose Gremlin when all your inputs are sim hardware and the output is one polished vJoy device: dual sticks, curves for pitch and roll, a modifier mode that turns buttons into a second layer. This covers most DCS, MSFS, Elite, and Star Citizen readers.
  • Choose UCR when an input is a keyboard, mouse, or something stranger, or when one profile must output to vJoy for one game and a virtual Xbox pad for another.
  • Do not choose based on which is ‘more powerful’ in the abstract. Gremlin’s depth is cockpit depth; UCR’s depth is input breadth. The wrong-axis depth just feels like clutter.
  • You can prototype in UCR and graduate to Gremlin — many sim players start with a quick UCR mapping, then rebuild it in Gremlin once curves and modes become necessary. Your vJoy configuration carries over; only the feeder changes.

Whichever feeder you pick, the layers underneath stay the same: vJoy provides the device (pick the right build with Which vJoy Build Should You Download?), the feeder provides the behaviour, and a tool like HidHide can hide the physical devices so games only see the virtual one. The Feeders & Tools hub walks through each feeder with its own setup guide, and vJoy vs ViGEmBus vs XOutput explains when the output should be a gamepad instead of a joystick at all.

Setup order and learning curve

Whichever feeder you choose, the install order is fixed: vJoy first, feeder second. Gremlin in particular expects the vJoy driver to already exist when it starts — it builds its virtual devices on top of the driver, and installing the feeder first just produces a confusing first launch. Configure the vJoy device itself in vJoyConf before opening either feeder: decide how many axes, buttons, and POVs the virtual device should expose, because both feeders map into that shape. Changing the device shape later means revisiting the mapping you built on top of it, in either tool.

The learning curves differ in shape, too. Gremlin rewards an evening of structured learning: its concepts — containers, modes, curves, and actions — compose, so the second profile you build is far faster than the first, and community packs for DCS and Star Citizen give you working examples to dissect. UCR is quicker to a first result, because a single mapping from one input to one output needs almost no concepts at all; its learning curve arrives later, when a profile grows many branches and the universal model gives you less sim-specific structure to lean on. Neither curve is a flaw — they are the same specialisation difference, seen from the learner’s side.

A concrete example each

A Star Citizen HOSAS player wants two sticks merged, a twist axis with a soft centre curve for strafing, and a mode where the left stick’s buttons become mining controls. That is a Gremlin afternoon: merge, curve, mode — its three signature features in one profile. A racing player with limited hand mobility wants the keyboard’s arrow keys, plus a mouse flick, to drive a virtual joystick a DirectInput game accepts, with a button toggling the mapping off in menus. That is a UCR afternoon: non-joystick inputs in, vJoy out, exactly the breadth its provider model was built for. Readers who recognise their own afternoon in one of those paragraphs have their answer.

Verdict

Sim cockpit with real sticks: Gremlin. Anything-that-is-not-a-stick as input, or mixed outputs: UCR. Both are free, both sit on the same vJoy driver, and switching later costs an afternoon, not a purchase. See the Alternatives & Comparisons hub for the driver-level comparisons behind this feeder choice.

Similar Posts