Skip to content

AIFX v0.2.5

Pre-release
Pre-release

Choose a tag to compare

View all tags
@Julm Julm released this 28 Aug 10:37
· 9 commits to main since this release
v0.2.5
7384f71

The macOS wizard could not complete an install at all, a workstation could be
told to ignore whatever it installed, and SeedVR2 came back cropped in Flame.

All three platforms ship this version. The SeedVR2 fix below is not
platform-specific; Linux and Windows were rebuilt from the 0.2.5 tree on
2026-08-28.

Fixed

  • SeedVR2 upscaling 1280x720 → 1920x1080 in Flame delivered a 1280x720 crop.
    The EXR on disk was correct; only what came back into the host was wrong. Flame
    is a fixed-format host (kOfxImageEffectPropSupportsMultiResolution == 0) and
    is spec-compliant when it ignores the RoD we return and allocates an
    input-sized buffer. The cache reader could not tell that apart from a tiled
    render — a (0,0)-(1280,720) window is "inside" a 1920x1080 result — so it
    extracted the corner. It now checks the canvas the host actually allocated
    before testing for a sub-region.

  • The macOS wizard's progress bar froze at 80% for the whole install, through
    the password dialog and the entire copy, which reads as a hung installer. That
    phase is one osascript invocation with nothing to count, so the bar now goes
    indeterminate instead of showing a fraction it cannot measure. A failed install
    no longer leaves the bar frozen at 80% either.

  • The macOS wizard failed at the last step with Operation not permitted. It
    staged the bundles in the app's confined temp directory
    ($TMPDIR/TemporaryItems/NSIRD_…). Staging runs as the operator and worked;
    the install runs as root via AppleScript, in a different security context, and
    the sandbox refused it the read. EPERM, not EACCES — being root did not
    help. Staging now happens in /tmp. The terminal installer (install.sh) was
    never affected.

  • setup-env.sh hijacked OFX_PLUGIN_PATH machine-wide. Setting up a build
    environment exported it into the developer's shell profile, pinning every OFX
    host on that workstation to one per-user directory permanently. Installing
    system-wide afterwards changed nothing: the host still read the old path, with
    no error to explain it. It no longer sets the variable.

    ⚠️ Workstations set up before this keep the export until it is removed by
    hand.     Check with echo $OFX_PLUGIN_PATH; if it is set, remove the
    export OFX_PLUGIN_PATH=… line from the shell profile and log out and back in.
    See Troubleshooting.

    This one is POSIX-only — the Windows setup script never touched the variable.

Added

  • install.sh warns when OFX_PLUGIN_PATH is set and does not cover the
    directory it just installed into — the one case where a fully successful
    install still leaves the host with no plugins.

Known issue — macOS blocks the installer

The .dmg is not notarised, so macOS 15+ refuses to launch the wizard. Use the
tarball's install.sh instead — a script run from a terminal is never
gatekeeper-assessed:

tar xzf aifx-0.2.5-macos-universal.tar.gz
cd AIFX-0.2.5-macos-universal
./install.sh              # /Library/OFX/Plugins — required for Flame / Flare

The Windows setup.exe is unsigned, so SmartScreen may warn on first run:
More info → Run anyway.

SHA-256

40f426216f9c434e80c9dee426a3e69657e00e25e404b3cc30129bc5de8e3d50  aifx-0.2.5-macos-installer.dmg
81bab7481cd673f04db702eb7d6938814735be64b646adf14940a4e0720f714c  aifx-0.2.5-macos-universal.tar.gz
8c6f9039f3de6bab93c7965337761ddf5f54167284a7112830ea03898f4a1c8c  aifx-0.2.5-linux-x86_64.tar.gz
f4faa85071b8ac23df81620bd62baff23127ea75adefe5b89e4b951bb803b36d  aifx-0.2.5-windows-setup.exe
216fc3f0d3f2727a95e3c8c5e8fe7839b1c9f2f2a0a72f3edb137a44a62a07f3  aifx-0.2.5-windows-x86_64.zip

Note — the .dmg was replaced in place on 2026-08-28 to carry the progress-bar
fix. Installer-only: no plugin code changed, the .tar.gz artifacts are the
originals, and every bundle still stamps version=0.2.5.

Assets 7
Loading