Skip to main content
Known Participant
October 16, 2026
Question

After Effects SDK: GetUniqueStreamID returns 0 — safe native keyframe access from custom UI callbacks?

Hi,

I'm developing a native After Effects effect with a custom Effect Controls UI. I need to access the exact native parameter streams belonging to the effect instance receiving a custom UI event, so I can implement stopwatch, keyframe diamond, previous/next-key and expression-aware controls safely.

Environment: After Effects 26.5.0.89, macOS arm64, SDK 25.6.

Using AEGP_StreamSuite6 (kAEGPStreamSuiteVersion6 == 11), AEGP_GetUniqueStreamID(AEGP_StreamRefH, int32_t*) repeatedly returns A_Err_NONE but explicitly writes 0 for distinct effect parameter streams and even built-in layer Opacity.

We confirmed this using two nonzero output sentinels and surrounding canaries. Across DRAW, multiple stream-acquisition routes, duplication/reordering and a separate AEGP command/idle test, 7,652 successful calls returned zero.

Stream values remain readable, and acquired references are disposed within their callbacks. I'm not assuming this behavior occurs in all AE versions.

Ordinary value edits work through the current PF callback's params[index]. However, the installed SDK documents PFInterface / AEGP_GetNewEffectForEffect availability in FRAME_SETUP, RENDER and EVENT/DRAW, not DO_CLICK/DRAG/KEYDOWN. PF_ParamUtilsSuite3 permits some current-effect keyframe inspection but does not provide native key insertion/deletion or expression-state inspection.

My questions:

  1. Is GetUniqueStreamID expected to distinguish these streams? Are there additional preconditions, a known issue or a fixed AE version?

  2. What supported API allows obtaining the exact current effect and parameter streams during custom UI input callbacks, for fresh expression checks and native keyframe operations?

  3. What identity/lifetime guarantees apply across effect duplication, reordering, deletion/Undo and project reload? Can stream IDs be reused?

  4. What SDK-supported pattern is recommended for custom stopwatch, diamond and previous/next-key controls on existing native effect parameters?

I'd prefer a supported current-callback solution rather than introducing sequence GUIDs, hidden parameters or a separate AEGP mediator.

I can provide a minimal read-only reproducer and logs if helpful.

Thanks!

    6 replies

    Community Expert
    October 16, 2026

    Hi there.

     

    What exactly is the purpose of using AEGP_GetUniqueStreamID? are you keeping track of some unkown stream? i mean, i usually optain streams using AEGP_GetNewEffectStreamByIndex or similar calls for layer streams. if you desribe the process, perhaps i could suggest means to reach that goal.

     

    as for AEGP_GetNewEffectForEffect, it’s valid during most of AE’s calls to an effect. with some rare exceptions such as “sequence setup” or “new context pf_event” calls, you can call AEGP_GetNewEffectForEffect and get any effect stream with the gotten AEGP_EffectRefH.
    i use that in my plugins during “pf_event draw” regularly.

    Translate
    Known Participant
    October 16, 2026

    Thanks, Shachar, for your help.

    These are known parameters of our own effect, and we already use AEGP_GetNewEffectStreamByIndex.

    Our original approach was to acquire the streams during DRAW, save their unique IDs, dispose of the references, then reacquire matching streams during subsequent custom UI interactions. The IDs were intended to prevent targeting the wrong effect instance after duplication or reordering.

    Our custom stopwatch and keyframe controls require fresh expression-state checks and native keyframe insertion/deletion. Ideally, we'd use AEGP_GetNewEffectForEffect(in_data->effect_ref) followed by AEGP_GetNewEffectStreamByIndex, acquiring and disposing everything within the same callback.

    However, SDK 25.6's AE_GeneralPlug.h appears to restrict PFInterface to FRAME_SETUP, RENDER and EVENT/DRAW. Interestingly, Adobe's own Supervisor example also uses GetNewEffectForEffect during UPDATE_PARAMS_UI.

    Could you clarify two points?

    1. Is the header restriction outdated? Is this acquisition approach officially supported during PF_Event_DO_CLICK, PF_Event_DRAG and PF_Event_KEYDOWN, including after effect duplication, reordering or Undo/Redo?

    2. In those same callbacks, can we safely perform fresh expression queries and native KeyframeSuite insertion/deletion operations on the acquired streams, or should those operations be handled elsewhere?

    A supported SDK example or reference covering these input callbacks would be particularly helpful.

    We would still invalidate pending interactions after context or project changes and avoid retaining native references across callbacks.

    Thanks again!

    Translate
    Community Expert
    October 16, 2026

    i’ve been using GetNewEffectForEffect during PF_Event_DO_CLICK, PF_Event_DRAG and PF_Event_KEYDOWN since forever, so the header comments are either outdated or wrong (some documentation errors are cought from time to time...).

    these events are very much valid for all project manipulations, including effect duplication, reordering and undo/redo.
    there could be logcal issues, such as if an effect deletes itself, then effect or stream ref disposals could cause issues. i don’t know where it stands today, but in the past i implented such operations using an idle_hook function on an aegp. i’d leave messages to the aegp on what to operate on during idle, and then execute these operations on the effects extreanlly instead of the effects operating on themselves mid-call.

    Translate