Add a bus_renamed AudioServer signal

[MewPurPur]

Adds a new signal and uses it to avoid unnecessary rebuilds of the audio bus editor, softening some lag spikes.

A slightly compat-breaking alternative to #81611 that also adds a new feature. The compat-breaking could be called a bugfix, depending on how you want to look at it. See the first few comments of the linked PR.

[MJacred]

: )

[MewPurPur]

Funnily, the old docs description is even more overbearing, it suggests any change in the AudioBusLayout is supposed to signal. Including... things like muting, bypassing, solo, volume changes, maybe even effects! I don't know what the signal was truly intended for at this point, so might as well invent a proper meaning now?

[YuriSizov]

This change makes more sense to me than the alternative (basically because I wrote the original comment in the modified code :P)

PS. We can preserve compatibility by adding another signal (or signals) that would be emitted for all the other activities. So we would avoid using bus_layout_changed entirely.

[MewPurPur]

Yup I saw in the blame. Since the signal never did what the documentation describes anyway, I think we can break compatibility here.

Unfortunately, I think that the initial idea was that the "bus layout changed" signal was meant to be for when the active AudioBusLayout changed - but the idea was forgotten over the eons as people interpreted "layout" as its standard meaning - the positioning of things.

I thought the intention of the signal was to alert things that the user-facing part of AudioBusLayout has changed, which does include renaming since buses can be accessed via their names. This is still a valid way to think of it IMO.

So, idk what to do with this, man. I hope I provided the facts and the different possible perspectives here.

p.s. I'll address the code style remarks after we decide what to really do.

[reduz]

looks good

[YuriSizov]

Note on merging: This is one of two alternatives to address the problem, #81611 is the other one. We likely need to pick just one, because they don't really make sense together.

[MJacred]

This one could be merged into master for 4.2 and the other one into 4.0 and 4.1, no?

[YuriSizov]

@MJacred This is not how we maintain Godot's codebase. Discrepancies like that makes it harder to support several branches at the same time, so the solution must come through all branches, or not come through at all. Unless it's something really really critical, but in this case it's just some lag.

If we want to preserve the compatibility and cherry-pick this fix, there are other options, as I've mentioned.

[akien-mga]

Thanks!