Unify design of AudioStream resource icons

[Meorge]

Describe the project you are working on

A VR game and a few non-VR games

Describe the problem or limitation you are having in your project

The icons for AudioStream resources don't seem to have a unifying design beyond their color.

The base AudioStream icon is very similar to the icon representing signals elsewhere in the editor. The AudioStreamRandomizer icon doesn't convey anything to suggest it is audio-related beyond the gradient matching other AudioStream-inheriting classes. The AudioStreamGenerator icon similarly doesn't seem especially tied to audio in particular - I could see it also representing statistics or metrics in general.

The music note "background icon" being shared amongst the AudioStreamWAV, AudioStreamMP3, and AudioStreamOggVorbis types suggests it may be representative of an audio stream in a file... except that AudioStreamPolyphonic, which (as far as I know) isn't tied to any audio files, and yet also uses this icon convention.

I recently submitted PRs to add icons for the new AudioStreamPlaylist (https://github.com/godotengine/godot/pull/95699) and AudioStreamInteractive (https://github.com/godotengine/godot/pull/95710) resource types. In them, I used the music note icon base, which brought up the topic of whether or not this was a good idea.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I propose that the base AudioStream icon uses the music note shape, and that all specific subclasses of AudioStream use the music note as a base with a smaller icon in front, like AudioStreamPolyphonic, AudioStreamWAV, AudioStreamMP3, and AudioStreamOggVorbis currently do.

Additionally (not included in my mockup below), to help users differentiate them at a quick glance, the small icon could potentially use a unique color. For example, the AudioStreamRandomizer's die icon could be red, while the AudioStreamGenerator's waveform icon could be green, etc. If we take this route, we may want to be careful to avoid using colors too closely associated with other parts of the engine (e.g., the same shades of red and green as Node3D- and Control-inheriting nodes).

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

NOTE: I mixed up the AudioStreamInteractive and AudioStreamPlaylist icons here, oops. The one with the cog is AudioStreamInteractive, and the one with the three horizontal lines is AudioStreamPlaylist. 😅 Please note, these are just quick mockups to get the underlying idea across. I think some of these (especially the AudioStreamMicrophone one) could use a bit more work to be easily readable. The main point I'd like to make here is just using the music note as a background icon that signifies "this resource inherits from AudioStream", just as the color gradient currently does.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No

Is there a reason why this should be core and not an add-on in the asset library?

The icons are part of the editor itself

[AThousandShips]

IMO this reduces usability, adding a tiny little detail on the side of a larger icon is very hard to see and especially notice quickly even without having vision impairments, I think we should move away from that design, not use it more

[Meorge]

Hm yeah, I definitely get what you're saying there. I wonder if swapping them around, so that the unique icon is larger and the "this is an AudioStream" icon is smaller? Coloring the sub-icons differently to differentiate them by color as well as shape could also help with this.

My objection to the current setup is mostly the lack of consistency with the use of the music-note icon - I don't recognize a consistent rule for when it is used, but it seems like it would be a good candidate for saying "this is an AudioStream". The base AudioStream icon looking extremely similar to the Signals icon (albeit horizontally flipped) also doesn't feel like the best choice to me, for consistency and grouping.

[Meorge]

Alternatively, the music icon can be a little misleading given that many types of audio (sound effects, microphone input, etc) aren't musical in nature. It would mean not having the unified icon shape, but perhaps the music note could be reserved for AudioStream types that are more explicitly musical, which would allow other types to be more easily distinguished by their unique icon shape?

[AThousandShips]

I'd say the rule is that all file based streams share a design, to me they are pretty consistent, I think only the polyphonic one needs a new icon to make it clearer and distinguished, otherwise they're distinct and clear to me

I'd not make any association with music as no aspect of the audio system has any music specific nature

[Mickeon]

I'd say the AudioStream icon doesn't look really good to me. Mainly for the reasons highlighted above. I think it should resemble an actual audio stream as you'd visualize it in your typical audio editing software. The other icons, except AudioStreamPolyphonic, seem fine by me, though.

[AThousandShips]

I agree the AudioStream icon looks like it's supposed to be an audio stream player

[Meorge]

Based on this discussion here, my thoughts on the icons are:

• AudioStream icon could resemble an audio waveform more (perhaps a larger version of the waveform icon in the AudioStreamWAV/MP3/OggVorbis icon?)
• Music note in icon should be dropped from:
  • AudioStreamPolyphonic - The "plus" feels like it'd be a bit clunky to me on its own, personally. I was thinking possibly multiple copies of the AudioStream icon "stacked" on each other, but I could also see that being hard to read/understand...
  • AudioStreamPlaylist - Perhaps just be the three horizontal bars (or maybe include a half-note to match the conventional "playlist" icon as noted here)
  • AudioStreamInteractive - Could just be the cog on its own?
  • AudioStreamSynchronized - Not exactly sure what would be used here. The idea from the AudioStreamPolyphonic one, of having the "stacked" icons, could also work here - but then again, we'd need to ensure it's still readable, and that it's also distinguished from AudioStreamPolyphonic since they serve different purposes.