The Fixo prefix and the Fixo / Fluxo split

If you've spent any time in the OctoMY™ codebase or studio you'll have noticed almost everything firmware-adjacent is named Fixo* — FixoPreset, FixoActuator, FixoLobeType, FixoLibrary, FixoStudioActivity. This is deliberate, and only temporary. Here's the story so you don't have to guess.

TL;DR

The Fixo prefix marks "the new, unified, statically-compiled firmware system". It exists to keep the new types separate from the legacy types they replaced. Once the legacy types are fully out (a planned single-commit prefix-strip pass), the prefix goes away in one clean operation. Until then, every new type carries it.

Where the name comes from

Fixo is from Latin fixus — "fixed, fastened, settled". The companion controller, Fluxo (from fluxus — "flowing"), shipped configuration over the wire at runtime so the firmware was generic. Together they expressed a static / dynamic duality.

Fluxo itself was a rename of the older ArduMY (Arduino-based generic firmware), done for symmetry with Fixo.

Fluxo was retired in 2026 because Fixo's embedded LLVM made the static path's only real cost — having to compile firmware — fast enough to be invisible. The duality is gone, but the Fixo name survived because it accurately describes what the surviving system does.

Why everything is Fixo*

The Fixo system was built alongside the legacy system, not as a replacement of it (initially). For a year or more, both systems coexisted in the codebase: Stanza (legacy) and FixoStanza (new), StanzaBook (legacy) and FixoStanzaTemplateBook (new), Lobe (legacy from liblobe) and FixoLobe (new), Controller / IController (legacy abstraction) and FixoController (new concrete class). The prefix was the safest way to keep them apart.

This let the team:

• Migrate consumers one at a time without renaming-stress on the legacy code
• Keep tests green at every step (legacy tests against legacy types, new tests against Fixo* types)
• Delete the legacy code in tractable chunks rather than one giant rename PR

When the prefix goes away

The plan is a single dedicated commit, scheduled after:

1. The last legacy controller (Servotor32, Fluxo, NullController) is gone — this happened in 2026.
2. IController itself is gone — in flight; it requires careful unwinding because libhardware UI activities still hold IController* and have to be relocated first.
3. liblobe and the legacy StanzaBook are gone.

Once all three are done, a single bulk-rename pass strips Fixo from every canonical class:

Until that pass lands, don't strip the prefix yourself — the rename has to happen all at once to keep the codebase coherent.

A second naming convention: "Manager", not "Management"

While we're talking conventions: the manager activities are named FixoPresetManager, FixoActuatorTypeManager, etc. — never FixoPresetManagementActivity.

Earlier code had a mix: ActuatorManagementWidget, ConstellationManagementActivity, NodesManagementWidget. In Phase 9 we did a sweep to rename every *Management* to *Manager* for consistency. So when reading older docs or PRs, you may still see the older spelling — the actual class names today are all "Manager".

This rule applies broadly across OctoMY™, not just in libfixo.

File and tag naming, while we're at it

A summary of the conventions used across libfixo:

If you're authoring a custom fixo.json (an actuator type, a stanza template, a preset template) and you stick to these conventions, the existing UIs will recognise and surface your additions cleanly.

See also

• Why Fixo — bigger-picture explanation
• Fixo Data Model — where the prefix lives in the type tree
• Fixo Controller — the controller class itself