Why do older projects break after updating the IEM Plug-in Suite?

Older projects can break after updating the IEM Plug-in Suite because versions v1.16.0, v1.15.0, and v1.3.0 introduced breaking changes. According to the official release notes, projects created with one of the previous versions "might not work as expected" once opened in a newer build. This is a known and documented consequence of those releases, not a sign that your session is corrupted. If you have not yet updated, the safe move is to finish or archive work in the old version first, or keep the older installer available so you can reopen the project in the environment it was made in.

What "breaking changes" means here

A breaking change is a modification to a plug-in's behavior, parameters, or data format that is not backward compatible. In practice, when you load an old project with a newer version of the suite, one or more of these can happen:

• Parameter values are interpreted differently, so a setting you saved no longer maps to the same sound.
• Automation or preset data written by the old version is read incorrectly or ignored.
• A plug-in's internal state is stored in a format the new version no longer expects.

The suite's own documentation frames this as a compatibility issue between project versions and plug-in versions, which is why the release notes point users to a dedicated Breaking changes article and the ChangeLog rather than describing it as a bug.

Which versions are affected

The current release listed on the site is v1.16.0 (30th September 2026). Note that the breaking changes are cumulative in the sense that each flagged version introduced its own set — a project last saved in a pre-v1.3.0 build has passed through all three.

How to handle a project that already broke

1. Check the version the project was made with. If you know it predates v1.3.0, v1.15.0, or v1.16.0, assume compatibility is at risk.
2. Read the Breaking changes article and the ChangeLog linked from the release page. These are the authoritative sources for what specifically changed in each flagged version and what to adjust.
3. Reinstall the matching older version if you need the project to sound exactly as it did. The suite is open source, so previous releases and the source code are available from the project's release and source pages.
4. Re-verify settings after opening in the new version. Even when a project loads, check parameters, automation lanes, and presets on the affected plug-ins rather than trusting the saved state.
5. Re-save under a new filename once you have confirmed the project behaves correctly, so you keep a known-good copy.

Reducing the risk before you update

• Finish or bounce critical projects before upgrading, so you have a rendered reference of the intended result.
• Keep the installer for your current working version archived, not just the newest download.
• Update one project at a time and compare against the bounced reference rather than updating everything at once.
• Treat the ChangeLog as required reading before any major-version jump, since it is where breaking changes are recorded.

What this does not tell you

The release notes state that breaking changes exist and that older projects may not work as expected, but they do not enumerate every affected plug-in or every parameter in the summary text — that detail lives in the Breaking changes article and ChangeLog. If your project uses the suite's Ambisonic plug-ins (which support up to 7th order) or the featured tools such as DualDelay, GranularEncoder, MultiBandCompressor, StereoEncoder, or RoomEncoder, check those specific plug-ins against the change documentation before assuming a clean load.