beckler/ahoy

Pirate MIDI Firmware Updater

Ahoy

Ahoy is a (hopefully) easy-to-use cross-platform executable designed to update the firmware for Pirate MIDI Bridge devices.

It's written in Rust, and offers a CLI and GUI. For the GUI, it uses the iced-rs framework.

Status

THIS SOFTWARE SHOULD BE CONSIDERED BETA, AND AS SUCH IS POSSIBLY UNSTABLE... but I think it's alright tbh.

If you're concerned, or believe you may have bricked your device, please read the section: Device Recovery

With that being said, I created this initially was a way for me learn about the handful of technologies involved. From the GUI, to the build process: this is mostly experimental. However, I like to create things with a purpose, and so I feel comfortable releasing it in it's current state, but there are a few more features I would like to implement as time permits.

Getting Started

Pre-built Binaries

Download the latest pre-built release for your machine.

All pre-built executables listed are 64-bit, unless otherwise listed. If you need additional archtecture or 32-bit support, I recommend building locally.

Use this guide for your specific machine:

• Windows
  • Intel/AMD
    • x86_64-pc-windows-msvc
    • [*untested] (32-bit) i686-pc-windows-msvc
• macOS (read caviet)
  • Apple Silicon
    • aarch64-apple-darwin
  • Intel
    • x86_64-apple-darwin
• Linux (read caviet)
  • Intel/AMD
    • [*untested] x86_64-unknown-linux-gnu

If you're able to verify these work on the specificed OS/Arch, please let me know via an Issue or PR, as I'm not readily able to verify them all myself!

macOS Caviet

This software is not notorized or signed, so it will be likely throw a trust error when running. If this happens, right click the executable, and then explicitly click "Open".

You can read more about this here.

Linux Caviet

You need libusb to run this, and due to some build issues, it's dynamically linked (instead of static like the builds for other OS's). If you don't have it installed, run the following (ubuntu flavored): apt-get install pkg-config libudev-dev libusb-1.0-0-dev

Building Locally

• Open your preferred terminal/console/shell
• Install Rustup.
• Clone this repo: git clone https://github.com/beckler/ahoy.git (if you don't have git, you can download an archive)
• Navigate to where you cloned/downloaded this repo and run the command: cargo run
• (Possibly Required) If you're having issues with a missing library, this does require libusb and any additional requirements that library requires. You can download and install it from here, or via a package manager:
  • (macOS): brew install libusb
  • (linux): apt-get install pkg-config libudev-dev libusb-1.0-0-dev

Feature Roadmap

• Hardware Revision Check
• Interactive Self-Update
• Code Signing/Notorization
• Backup/Restore
• Supporting future devices (like click and uLoop!)

Device Recovery

Note: These instructions are for the Bridge 6 and Bridge 4 devices.

If you're concerned, or believe you may have bricked your device, there is a path to reapply the update! The creators of the Bridge devices had great foresight for this exact issue, and you should do the following:

• DON'T PANIC
• Download the latest release from the Pirate MIDI Website.
• Make sure you're not supplying power via the 9V port!
• For the Bridge6, hold FS6 while powering up/plugging in a USB cable.
• For the Bridge4, hold FS3 while powering up/plugging in a USB cable (Thanks Simon!).
• Wait about 10-15 seconds, as the device won't appear to do anything.
• Run the command: ahoy install --skip-bootloader ~/path/to/your/downloaded/firmware.bin
  • As a backup method, you can use the dfu-util command as laid out here (click "Details & Instructions").

Build Process

Most of the build GH action and scripts were pulled and modified from the Starship project!

ahoy's Issues

Refactor final page

When the install is done, the app gets in a weird state.
So we should refactor and figure out a good final state.

Implement Backup/Restore

And any GUIs needed

Refactor hardware release logic

The hardware selection via versions is brittle, is seems to have issues on occasion.
Refactor so that filtering occurs closer to the initial calls, instead of in the UI.

Add zip decompression for self-update on Windows

I think this is why self-update is failing on some windows installation.
I need to verify, but I think I specifically need the DEFLATE algo.

Handle orphaned thread

The USB listener has a thread that gets orphaned when closing the app. It causes it to hang when the close window signal gets sent for graceful shutdown.

Make self-update more interactive

Currently, self-update only works from the CLI, but CLI isn't available on windows due to the windows_subsystem issue.

Implement stylistic overhaul

Use the colors/icons/assets provided to match the style guide

Create working Windows build + installer

• Handle hanging terminal window
• Create DFU driver (using libusbK)
• Create installer that includes libusb + DFU drivers

Look into Windows driver issues

There is a stability issue with the libusbk windows driver install. Look into making it more stable.

Implement hardware revision check

Firmware versions will follow semantic versioning with an additional place for the hardware revision.

• i.e. 1.1.1.1 vs 1.1.1.2

We need to implement a check that will review the hardware revision (from CHCK) against available firmware versions and then filter out selections based on that revision.

Code sign/notorize builds + installers

This should stop OSs throwing errors and such upon launch and opening.
The release GH action current contains instructions (that are commented out) to do this automatically, but it needs certs to run.

• Windows
• macOS
• Linux (code signing is not required)