Spawnable empty SourceEffectPresetChain instances (Audio Mixer)

Here’s something I’m trying to do which I think is not possible right now, but I want to document it a) to make the case for its possible addition in future UE versions and b) on the off-chance that someone can suggest a workaround :slight_smile:

We’re dynamically spawning synth instrument instances, where an instrument is an instance of a BP class that can contain a Modular Synth, a Granular Synth or a custom multisample player. We set these up from a user struct-based datatable which acts as our instrument bank. The bank also contains arrays of Source Effect Preset Settings, as well as an array of Effect types referencing each setting.

This means we can construct a per-instrument Source Effect chain which we can re-order dynamically, and which can contain multiple instances of the same effect type with different settings (e.g. a 120hz EQ cut at position 0 in the chain, then a compressor, then a 1400hz EQ boost at position 2).

To be able to do all that without having to create and organise a directory full of Preset assets in advance is great for workflow and reusability! The only stumbling block is that it seems to be impossible to dynamically add SourceEffectPresetChains to audio components (or remove them); nor can they be linked to a local variable in your BP. They have to be explicitly set in the audio component’s Effects config. While submix and bus stuff can be changed at run-time, SEPCs can’t.

So the result is that, if I use an empty SEPC asset as a placeholder for all instances, every new instance overwrites that Chain with its own Effect Presets and so all ‘instruments’ end up with the same effects chain (ie that of the last instrument to be spawned). One of our C++ coders wonders if the SEPC asset type can be forced to have a UPROPERTY of ‘instanced’ (I don’t know how to do this, but I’ll ask him to give it a try).

Is there any reason why this wouldn’t work? I mean, is there any Audio Mixer ‘magic’ going on that means we won’t be able to mess without building our own fork of the engine? Because we’d like to avoid that if possible :slight_smile:

And, of course, can anyone think of a workaround for this - maybe something obvious that I’ve missed? Attempts to use ‘Construct Sound Effect Source Preset Chain’ to assign an instance of a Chain to a local variable were my first thought, and this works, but they then can’t be applied to the audio component…so no dice. Any suggestions appreciated!


Sorry to bump, but…can anyone suggest a solution or workaround to this?

Tl;dr: I’m spawning <n> instances of a sound actor and I want each to have its own unique SourceEffectPresetChain, which is also constructed and set dynamically (ie not by explicitly referencing an Asset in the actor’s sound component Details tab).

Yeah I’m 100% with you. Would be real nice to be able to create dynamic instances, like we do with materials and other stuff! This goes for most objects/components.
Last thing I heard, these things are meant to be focused on eventually, but not before Fortnite was switched over to new mixer? Which is/was a big task. At least that’s how I remember it, was a while ago.

A workaround is creating a large enough pool of empty chains upfront, then design the system so it uses and re-uses chains from that pool.

Thanks Arthur - I tried this, but found that if I create the empty chains as assets, I can’t programmatically assign them to objects at spawn-time (as they have to be explicitly set in the Details field). And dynamically constructing chains seems to work in and of itself, but that isn’t any help since there’s no way of plumbing those chains into the audio mixer at runtime. Unless you’ve found a way, in which case I’d be very grateful to hear about it!

Hhhehehe, my other workaround; a switch case between a bunch of ‘Add synth/audio component’ blueprint nodes. Each node with a different Source Effect hard-coded in it’s settings… So, when constructing an audio/synth actor, it switches between those nodes, and returns one with the correct chain. This worked in PIE and packaged game, but I only had 7 different chains… Still I can imagine this working, with a big enough pool and a control overview system to keep track of which of them goes in and out of use…But it’s not elegant or beautiful!

Thanks for sharing! Might just be the temp fix I need :slight_smile: