Artiphon filed Chapter 7 in August 2025. Firmware updates stopped, the cloud services are winding down, and the desktop app loses features with them. This is an effort to document the lineup well enough that the instruments keep working without the company behind them.
Four devices are in scope: Orba 1, Orba 2, Orba 3, and Chorda. Nothing has been open-sourced, and there is no sign that it will be.
Several preservation approaches to consider and investigate:
Three outcomes would each be worth having on their own. A community replacement for the desktop app, so presets and settings survive the cloud going away. Enough protocol documentation that anyone can talk to these devices directly. And for Orba 2/3 and Chorda specifically, where the firmware cannot be read out, a rebuild of its synthesis engine from the outside.
| Device | Codename | Main SoC | Wireless | Firmware |
|---|---|---|---|---|
| Orba 1 | delorean | STM32F730R8T6, Cortex-M7, 64 KB flash | ESP32-SOLO-1 | recovered |
| Orba 2 | temari | NXP i.MX RT10xx | ESP32 | AES-128, eFuse keys |
| Orba 3 | sriracha | NXP i.MX RT10xx (inferred) | ESP32 | AES-128, eFuse keys |
| Orba 3 Play | biscuit | NXP i.MX RT10xx | ESP32 | AES-128, eFuse keys |
| Chorda | accord | NXP i.MX RT106x | ESP32 | AES-128, eFuse keys |
The ESP32 is a BLE MIDI bridge in every device, proven from recovered firmware on Orba 1 and Orba 2. Orba 1's STM32 runs bare metal with no RTOS. Its board is marked Main PCB DeLorean X9, 2021.
All of them execute encrypted from flash using NXP's bus encryption engine, with AES-128 keys burned into eFuses. There is nothing to attack statically. The only practical route is a live debug dump of the decrypted address range, taken after the bootloader has configured decryption, at which point the chip hands over plaintext without any attack on the cipher.
Whether that is possible on a given unit comes down to one fuse, which has three states rather than two:
JTAG_SMODE | State | What a probe sees |
|---|---|---|
0x0 | Open | Full register and memory access |
0x1 | Secure | Port enumerates, access faults without the challenge key |
0x2 / 0x3 | Disabled | Nothing at all |
Protocol and struct documentation from holofermes/orba-protocol and holofermes/orba-console, cross-referenced against independent disassembly rather than taken on trust. Earlier reverse-engineering by subskybox, IanHalbwachs and Batninja. The chip identifications were corroborated by a forum teardown thread where someone read the markings off an opened unit.
From the firmware analysis, the Orba 1's chips are:
| Component | Notes |
|---|---|
| Main processor | STM32F730R8T6, a Cortex-M7 at 216 MHz with 64 KB of internal flash, 61,336 bytes of it used. Nothing executes from external memory: the 124 KB audio engine lives in SRAM1 at 0x20010000 and is copied there from the SPI flash at every boot |
| External SPI NOR flash | A Winbond W25Q40-class part, 512 KB, identifying as EF 12, on SPI3 with chip select PA15. It holds the SRAM1 audio-engine image, the presets and the settings block, so the device is not running everything from internal flash. The device does not boot without it: with the chip erased the firmware loads no engine and stalls |
| Motion sensor | An LSM6DS3-class accelerometer and gyroscope, also on SPI3, chip select PA4, answering 0x69 to the identity register |
| Capacitive touch controller | A Cypress PSoC on SPI1, chip select PB2, reset on PC4 and a data-ready line on PB12. It streams a 100-byte report with no command needed, 25 signal values and 25 raw values, covering the eight pads plus the centre A electrode as sensor 24. Its firmware is updatable through the Cypress bootloader commands in the app protocol |
| LED driver | An ISSI IS31FL3236, 36 channels, on I2C3 at 7-bit address 0x3C with a shutdown pin on PC15. It drives the eight RGB pad LEDs, three channels each, and nothing else: the spare outputs never light, which is how we established there is no separate indicator LED |
| Wireless module | An ESP32 on USART3 at 115200 baud, with enable on PB14 and IO0 on PB13, handling Bluetooth Low Energy MIDI and the Connect app link. Its own firmware is flashed through a serial pass-through mode the STM32 offers |
| Audio output | No codec chip in the signal path worth naming: the STM32's SAI2 block B feeds a DMA stream at 48 kHz, and the volume is a timer PWM channel on PC8, with a haptic motor on PC6 |
Found a good condition Orba 1 locally that will serve as guinea pig for custom firmware and hardware modifications. Should be here in a day or two, then it's time for the first unofficial firmware version. What feature should we try to add first?
Made significant progress on the hardware emulator today. Nearly all functionality works as expected, with some unavoidable latency. Ultimately this will serve as a nice experimental platform but likely not a good replacement for actual hardware. The next step, as I wait for Orba 2 hardware, is to attempt to simulate the audio path directly in software. Removing the hardware emulation should simplify things, and remove the latency.
The Orba 1 has a serial NOR flash on SPI3, 512 KB class, and it cannot run without it.
flash is 64 KB. It has to be stored somewhere else.
from the SPI flash at boot, the engine appears in RAM from it, and the device plays. With the flash erased it reads 8 bytes, loads nothing, and stalls.
image into it, power-off writes the settings and loops, and the update bundle carries the engine segment for exactly this.
EF 12, a W25Q40, though a chip answering withanother ID still boots, so the exact part is inferred and its presence is not.
What a bigger one would buy, measured under emulation: a W25Q128 is a drop-in, sixteen megabytes on the same three-byte commands the firmware already uses; the bus streams four 48 kHz mono voices at its current clock and thirty-plus after one prescaler change; the CPU has room, eight synth voices using about a third of it. RAM cannot hold samples, only 29.6 KB of 256 KB was never written under a heavy workload, but it can buffer a few voices. The obstacle is code: 0.15.2 has no sample playback, there is no source, and free code space is a few kilobytes. A sampler would be a binary patch into the engine image, developed against the emulator first.
Basic functionality and audio works, but needs a lot of work to actually be considered a usable Orba 1.
Found a reasonably priced Orba 2 on eBay with still 2 days to go. Fingers crossed I win the bid, it will go a long way in helping figure out how far we can go in our preservation effort. Next up, Chorda.
Someone posted a teardown of a broken Orba 1 they had picked up on eBay for about thirty dollars. The die marking on U1 is legible in one of the photos:
STM32F730R8T6 — ARM Cortex-M7R = LQFP64 package8 = 64 KB flashThe flash size agrees with what I had already derived from the firmware image independently, which is the sort of corroboration worth having. Board is marked Main PCB DeLorean X9, © 2021. That closes the exact-package question two earlier notes were both carrying.
Orba 1's audio is SAI2 Block B, fed by DMA2 Stream 6. SPI3 is the link between the STM32 and the ESP32. I had conflated the two earlier.
The Orba 1 firmware provided some good insight into the hardware:
delorean_crc 0.15.2.hex — the STM32F730 main firmware, the synth engineesp32_delorean_047ca2c3.zip — the ESP32-SOLO-1 BLE MIDI bridge21_X0_CY8C_Touch_A0_2988ebe.cyacd — the PSoC touch controllerThe Mac installer is missing the ESP32 packages that the Windows one carries. The Windows installer also happens to contain an Orba 2 ESP32 bridge firmware, which is a useful cross-reference even though Orba 2's main firmware is encrypted.
Orba 2, Orba 3, Orba 3 Play and Chorda all run NXP i.MX RT parts and all use the Bus Encryption Engine: AES-128 execute-in-place decryption with keys burned into eFuses. There is nothing to attack statically and brute force is not a real option.
The practical route is a live SWD dump of the decrypted address range, taken after the bootloader has configured the PRDB. At that point the chip is handing you plaintext for free; you are reading memory after decryption rather than attacking the cipher.
Whether that is possible at all comes down to one fuse. On these parts JTAG_SMODE has three states, not two:
0x0 — open, full register and memory access0x1 — secure, the debug port enumerates but access faults without themanufacturing challenge-response key
0x2 / 0x3 — no debug, the probe sees nothingSo the first real test is cheap: wire a spare Pi Pico running picoprobe to the candidate test points and see which of the three you get. That settles whether this is worth spending money on, before buying a proper probe.
Hopefully I get my hands on a bricked or cheap Orba 2/3 to test the theory.
Artiphon distributed firmware from Google Cloud Storage. I took a manifest of it before the billing account lapsed: 224 objects, about 195 MB, across nine buckets.
The awkward part is that bucket listings still answer:
https://storage.googleapis.com/storage/v1/b/<bucket>/owhile the objects themselves now return 403. So I know exactly what exists and cannot fetch any of it.
Once Google garbage-collects the suspended project this is gone for good. Getting the actual bytes is the most time-sensitive thing on the whole list. Avenues not yet tried: requester-pays, asking the trustee directly, or GCS support for orphaned public data.
If the Chorda dump never happens, the alternative is rebuilding its sound from the outside rather than reading its code.
Target board is a Waveshare ESP32-P4: dual-core RISC-V with a hardware FPU and 32 MB of PSRAM for the DSP, an ESP32-C6 alongside it for wireless, and an ES8311 codec on I2S for output. That split is not arbitrary — it mirrors Orba 1's own STM32-for-synthesis, ESP32-for-radio arrangement.
The method is capture, analyse, match: record every patch off a real Chorda, pull an acoustic fingerprint per patch with STFT analysis, implement the voice engine using the Orba 1 disassembly as a structural prior, then iterate on parameters against a scripted spectral distance until the two agree.
The Orba 1 topology is the working hypothesis for what Chorda looks like inside: two morphing oscillators, noise and ring modulation, three envelopes, a resonant multimode filter, a waveguide blend, reverb and delay.