OK so this is a question but also a heads up for people who might get caught out by this. (I'm not looking for alternative solutions here, just would like to know the reasons why the system gives these results).
#MetaSound culling and variables
teal jungle
So let's say I have a bunch of windows and I want some rain sounds for them. I have a 'Windows' blueprint that has this in it.
In my level BP (or other) I'm doing this to fade in/out the rain.
Controlling this MetaSound thats in the 'windows' BP.
When I fade out the sound (execute trigger parameter) then exit and re-enter the attenuation extents of the sound it starts playing again. Presumably since it has dropped to volume 0.0 and has been culled so when it restarts it has no ‘memory’ of the Gain 0 variables new value, it just plays the default as set in the MetaSound. (Even though the audio component is still active). Play when silent cures this, but I don’t want to use up the voices.
So.. an alternative is to set a float input.
And indeed this works, even when the sound is not set to 'Play when silent'.
What I don’t get is why after being culled the metasound seems to retain the value of the Input, but it does not retain the value of any internal variables??
Some videos here.
Execute trigger paramter - the sound restarts:
Execute trigger parameter with play when silent enabled. All good, it stays silent, but voices are being taken up:
Set float parameter with Play when silent false - it works:
But why does the value of a variable that's set inside a Metasound get lost when it's culled, but the value of an input does not?
Thanks!
rugged junco
i could be completely wrong here, so maybe best not to listen to me
Could it be that when when the metasound with variable is culled its because its technically going out of scope? and the input one remains because its a pointer to a variable elsewhere (i.e your BP)
which isn't going out of scope
So metasound goes "i need this value from this address, which has been set to this" but the metasound goes back to initialised settings simply because the whole thing "as function" is being started again
teal jungle
Hey Jamie! Thanks - OK yes that makes sense. It would also explain why this works.
So the lesson is to avoid using Triggers to set variables inside MetaSounds, use variable inputs instead. (Obviously all this only applies to looping / continuous MetaSounds since for One-shots we'd always assume you'd need to set any values you want changing from the defaults each time.)
jovial apex
When did we get threads!? This is great!
I believe the values of the input params are cached on the audio component. So my guess is when the sound is stopped underneath the AC, the AC still has the cached values and uses those when you restart it.
This is not intentional... To fix this we'd need to bubble up the culling fo the sound back up to the AC so it knows to clear out any cached parameter values.
I didn't dig into this to verify my theory. Just read this, and it's my current theory based on my understanding of teh code. I haven't looked at the AC code in a while though so I may be wrong. But this makes the most sense.
FWIW the reason we cache the values is that people like to set values on the AC before playing the MS. In the past, when those values werent' cached, peopel complained about the values not being applied tot eh sound when it played. So you'd have to play, then in the same tick set your init values, which isn't super great BP UX.
I suppose you could argue that if you're using the same AC you MAY want to have the same params sent to the same sound (but a different instance). I can see that being an intended use-case too.
This is especially true if you're using the AC to control and playback multiple instances. You want the input params you applied on the AC to work across all instances of the sound (including new ones).
There was a point where we were doing rapid-fire oneshots with a single AC and using Quartz to schedule machine-gun one-shots.
(we now do that all in MS)
teal jungle
When did we get threads!? This is great!
Threads for the win!!
Set values before playing - yes that makes sense for one-shots at least. So A rather than B:
In my use case I was working towards a weather system where the Set floats are controlling crossfades between rains sounds etc. So if these values weren't cached in the AC then the issue would occur everytime you leave and return the attenuation extents, since there's nothing retaining the previous values when the sound restarts.