frontend: show track label on hover in advanced audio settings

[zack6849]

Description

Modifies the advanced audio settings menu to show the track name as configured in Settings > Output > Audio > Advanced Mode, eg:

Motivation and Context

Ideas: https://ideas.obsproject.com/posts/2247/show-track-names-on-advanced-audio-properties-pane

Say you set a custom name for Track 3 as "Game Audio" and Track 2 as "Browser Audio" and Track 4 as "Discord" or something, when I'm in the advanced audio settings screen, it's impossible for me to remember which are which, and configure which audio streams go to which tracks at a glance

Example of the problematic UI:

Screenshot of the proposed fix:

I figured using the a11y based label as the fallback instead of the number works better, IMO "Games" and "Track 4" reads better than "Games" and "4", but feel free to let me know if breaking that is a problem and I'm happy to change it

There are a few places in the codebase with this pattern that could probably be improved, not sure if this is a good candidate for a wider refactor in the future or not, but the guidelines say to keep changes small

How Has This Been Tested?

Tested manually on x86_64 Arch Linux 7.1.6

I built the code and ran obs, and tried things like long strings and short strings, and no strings at all, I don't expect this to be something that would possibly break any functionality, I wasn't sure about a maximum length on these strings, i don't see an enforced max, so I didn't want to set a rule, however I didn't want one really long source name to push all the others to the end, and even showing "This is a re.." gives you a lot more context than "6", if you hover over it, I set the tooltip to the full version on hover, so people can see the full name if they're confused, but doing so required QFontMetrics, if that's an overstep let me know and I'm happy to revert it to just showing full length strings, I also considered maybe extracting it to a separate matrix beneath the main mixer list, but that seemed a lot more heavy-handed

Types of changes

• Tweak: Change the label of the check boxes in the advanced audio UI
• Code Cleanup: use a loop that references the MAX_AUDIO_MIXES parameter instead of re-writing the same code n times

Checklist:

• I have read the contributing document.
• My code has been run through clang-format.
• My code follows the project's style guidelines
• My code is not on the master branch.
• My code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

AI Disclaimer

• I have used AI tooling in the creation of this PR

the above is strictly in the sense that I asked AI questions about project structure and CPP conventions, I wrote the code, I did not tell claude "pls make this do this" and then submit a PR

Open Questions:

• Should we change the accessibility label to use this instead? I would think for the same reason, showing the track name (eg: "Games" instead of "Track 4") is additional context and helps screen reader users more, but I'm hesitant to change that without further discussion since it's probably something that requires broader discussion

[Warchamp7]

I understand the desire here but I don't believe adding even more visual noise to this window is a good solution.

[zack6849]

@Warchamp7 is there an alternate approach you would be open to I could take on? I'm interested in improving this feature, if rework is required i'd rather rework it, if possible, but if that's putting more burden on you guys I understand

Eg: what if we just changed it to at least set the tooltip text to the full custom name, it's still more visual noise, but it's opt-in and only on hover, so it changes nothing by default for any users, and still fixes this usecase that's had an open ideas thread for years about it and makes the screen more useful

[zack6849]

As discussed on discord, I've changed my branch to keep the same old UI, but only show the labels on hover as tooltips as a short-term solution, screenshot below

[PatTheMav]

I agree with @Warchamp7 that the global settings dialog is not the right place for this information, particularly as it serves a different need/purpose. And to add to that I'm also unsure about the value of this dialog apart from "it's there to provide more knobs", because I don't see any use case where I would use different bitrates, potentially yielding a recording with worse audio quality than others, but I'm happy to be educated about use-cases where this is necessary?

(Personally I'd require something different entirely: I'd want to have one channel use AAC stereo, another channel use ALAC stereo, maybe another use multichannel audio, which requires different encoders per channel (which obviously now need more than different bitrates per channel), which is actually not possible in OBS as far as I can tell?)

Because otherwise I'd advocate to remove that entire screen and have a single, unified, bitrate for all channels of a recording, which should usually contain the highest quality possible anyway (so that it can be re-encoded or edited in a proper editing software later). Which would remove the need for this PR entirely.

---

And on another note I'd argue that the flow of information should actually be the other way around: If someone actually sets different channels up to use different bitrates (a use case I don't fully understand yet, see above), then that's effectively the "technical setup of the output".

When choosing which sources to punt to which output, that's the place where that information should be exposed, so the label should expose the bitrate so a user understands "yes, I'm sending this source to the 96kbit encoder and it will sound worse for it".

[zack6849]

@PatTheMav, a little bit of context that ended up only in discord, after @Warchamp7's comment, I reached out and asked if a tooltip-only version would be acceptable as a stopgap until the planned redsign of the window, I was told yes in discord, and asked to keep it simple, so I reduced the scope of the pr, the only thing the PR does now is show the name of the track on hover, and then the PR was re-opened after being declined with the now-reduced scope

If your question was directed at me about bitrates, this change wasn't to do with bitrates, it's about the track names, I record game, discord, mic, and system audio, all to their own separate tracks, so they can be mixed in an editor later, I name them in output settings because that's the only place OBS lets you. In this dialog that actually lets you configure which outputs go to which tracks, it just shows 1-6, not track names, which is not useful, how do i remember what track 3 was? Was it discord? Game audio? Both? Who knows! I guess i'll have to screenshot the settings page and reference it while I edit the mapping otherwise. This tooltip on hover fixes that.

Ideally, i'd much prefer a system that showed the names by default, but I understand not wanting to make the ui even more noisy for people, especially if they're not doing what i'm doing with tracks and thus don't care, that's why I think the tooltip on hover is a happy balance between the two