Mixer: exposing "Send level" parameter inadvertently marks all possible Send levels as exposed

Unity Engine
,
1

Hello, first post here!

Getting to know the Unity Mixer, I noticed that exposing send levels isn’t working as I expected.

I have multiple Sends set up in the mixer, and when ever I try to expose the Send level of any one of these (using the Inspector, right click on the Send level parameter, then “Expose Send (of Atmos1) to script”, for example), it exposes ALL send levels in the mixer in one go. This also marks them all with the little arrow that indicates the parameter having been exposed.

Only one entry is added to the Exposed Parameters list, and I’m unable to expose any other Send level parameters, for any other Send, no matter where they are located in the mixer and what is receiving them - as now they all just say “Unexpose” when right clicked. If I choose to unexpose any Send level in this manner, no matter which one, it unexposes them all and removes the single Exposed Parameters list entry.

Exposing any other parameter that I’ve tested in this manner, even ones that are sharing a name (like individually exposing the “Cutoff freq” of a handful of Lowpasses in the mixer) works as expected: they are treated individually, get one entry in the parameters list each, and can be unexposed one by one.

I’m on Unity 2019.2.16f1, Windows 10. Thanks for any insight on this!

Edit: I missed an error message, and it seems to be exactly this issue: Unity Issue Tracker - "Assertion failed on expression" error is thrown when Audio Group's "Send level" variable of "Send" effect is exposed

As I posted in the comments of that issue: in order to have “real” send level control from code, using exposed mixer parameters, I guess one could first insert a stationary always-on-100%-send that sends into a separate dummy track, then expose the attenuation parameter on that extra track - and then, in turn, send downstream from there into the actual desired send target. Control the exposed attenuation parameter from code to effectively get dynamic send level control. It does get a bit messy if you have a lot of groups and stuff to send, but at least it works for now.

1 Like
2

same here. it is not solved!

3

Experiencing the same issue in Unity 2020.3.1f1

There only active bug ticket I could find on the topic is marked as “Fix in review for 2021.2.X” at the time of writing:

Forcing us to implement Lunar-Ladder’s suggested workaround.

4

Following up on this,
I’ve implemented the ‘dummy track’ workaround.

Although I cannot get it to function properly.
The logic seems sound, but it would appear I’m bumping into a separate issue altogether:

I’ve set it up as follows:

7013671--829750--upload_2021-4-7_8-23-24.png
7013671--829750--upload_2021-4-7_8-23-24.png1124×515 60.1 KB

  • Ambience Master > Ambience Reverb Send > Reverb.
  • All send levels are at 0.00 dB.
  • Attenuation Volume of ‘Reverb Ambience Send’ is exposed an variable at runtime.
  • ‘Reverb Ambience Send’ is Muted to avoid duplicating the original dry source.

That last point is not elaborated on in the original workaround description.

This setup seems to accomplish setting up an ‘exposable send’ workaround,
however, I confirmed that audio received on a muted channel still plays even when it is muted.
I’ve reproduced this behavior in a separate project and filed a bug report.
See the attached project ‘AudioMuteReceiveIssue’, it contains a readme file with details.

If I gather correctly, the only remaining option to prevent the dummy channel from duplicating the source, is to silence it manually, by adding a filter effect after the ‘send’.
But at some point I have to question if I really want to get a workaround working by using another workaround.
If nothing beter comes up, we are forced to go in this direction until the ‘exposing a send parameter’ issue is fixed.

Questions:

  • Is there a way for a group not to route to the master track.
    Since this thread has not been responded to in quite some time, I figure I might be missing something obvious.

  • Can it be confirmed that - a muted group still contributing routed audio to the master - is not by design?
    And if it is, I’m not sure of why that would be the case.

  • Any less elaborate strategy for exposing sends is also welcome, or any general information regarding this issue.

Thanks in advance!

7013671–829801–AudioMuteReceiveIssue.zip (103 KB)