Blueprint-accessible Programmer Instrument verification in Animation Preview

Unreal Engine
1

The Problem

FMOD recommends Programmer Instruments as the preferred approach for multi-language audio implementation. However, there is currently no Blueprint-accessible way to verify Programmer Instrument behavior in the Animation Preview window.

Here is the chain of constraints that leads to this dead end:

  1. Programmer Instruments require EnableTimelineCallbacks to be set to true.
  2. EnableTimelineCallbacks is only available on UFMODAudioComponent — it is not supported on raw FFMODEventInstance.
  3. UFMODAudioComponent::Play() calls PlayInternal(EFMODSystemContext::Runtime) unconditionally.
  4. In Animation Preview, the Runtime FMOD system has not yet been initialized (it only starts when PIE begins), so GetEventDescription() returns null and the component produces no sound.
  5. PlayInternal() with the Auditioning context would work — the Auditioning system is always initialized in the editor — but PlayInternal() is a private method and is not exposed to Blueprint.

By contrast, PlayEvent2D and PlayEventAtLocation do work in Animation Preview, because they call GetEventDescription() with the default Max context, which correctly falls back to the Auditioning system when not in PIE. However, these functions return a raw FFMODEventInstance with no support for EnableTimelineCallbacks, so Programmer Instruments cannot be verified through them either.

The result is a hard gap: for any sound that uses a Programmer Instrument, there is simply no Blueprint-level path to hear it in Animation Preview. The only workaround is PIE, which is significantly heavier and slower for iterative sound design work.

For sounds that do not use Programmer Instruments, a workaround does exist — checking the world type or owner class in a custom AnimNotify and routing to PlayEventAtLocation in preview and PlayEventAttached in-game. But this workaround is not available when Programmer Instruments are involved.

What We’d Like

Any of the following would resolve the issue:

  1. Add a Blueprint-callable public wrapper around PlayInternal for the Auditioning context — for example, a PlayForPreview() function tagged with DevelopmentOnly, so it is automatically stripped from shipping builds and cannot accidentally be used in production.

  2. Add EnableTimelineCallbacks support to FFMODEventInstance, so that the existing PlayEvent2D / PlayEventAtLocation path (which already works in Animation Preview) can also drive Programmer Instruments.

  3. Add an option to UFMODAudioComponent to allow it to fall back to the Auditioning context when played in an EditorPreview world, so that the normal Play() → PlayEventAttached workflow works transparently in Animation Preview.

Option 1 seems like the lowest-risk change — a single thin public wrapper with a DevelopmentOnly tag would have no impact on runtime behavior and no risk of the regressions that may have caused this path to be closed off in earlier versions.

Why This Matters

Localization via Programmer Instruments is a workflow that FMOD itself recommends. A sound designer following that recommendation has no way to preview the result in the Animation Preview window without either switching to PIE or modifying the plugin’s C++ source — neither of which is practical in a large team environment with strict change management processes.