Add quality-of-life controls to AudioStreamRandomizer inspector

[MajorMcDoom]

Describe the project you are working on

Any project

Describe the problem or limitation you are having in your project

• There is no way to preview an AudioStreamRandomizer from the inspector.
• There is no way to clear all the added streams from an AudioStreamRandomizer except to manually delete each one.
• The only way to add streams to AudioStreamRandomizer is to manually increment the stream list to the right size, make sure you are navigated to the correct "page" in the list (limit is 5 entries per page), and manually add the streams one-by-one.

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

• Add play/stop controls to the AudioStreamRandomizer, similar to AudioStream, but without the need for waveform visualizer, timeline, or time display. It's just to preview the playback with random selections and pitch/volume variance.
• Add a button to clear the stream list.
• Add one or both of the following:
• A) Support dragging stream(s) directly into the list without needing to drag into a specific slot. In a manner identical to regular exported array properties.
• B) Add a button to automatically populate the streams list with AudioStream resources from the same folder whose names match: <name of randomizer><_ or -><counter>.

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

See above.

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

It can technically be done if a script is attached to every AudioStreamRandomizer, but I believe the aforementioned features to be basic usability.

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

See above.

[Calinou]

B) Add a button to automatically populate the streams list with AudioStream resources from the same folder whose names match: <_ or ->.

I would probably automatically do this when you load a new sound into the array. Check for other existing audio files that haven't been loaded yet with an incrementing number suffix (with various common separators), and load them automatically after the newly loaded sound.

For instance, loading sand0.ogg would check for sand1.ogg, and sand2.ogg if sand1.ogg exists, and so on. The number ordering needs to be contiguous for this to work, but it can start from any number. Handling leading zeroes might be difficult, but it may not be worth doing as you'll rarely have more than 10 random variations of a sound (if starting from 0).

I intend to do something similar in BaseMaterial3D when loading an albedo texture (to automatically load other material maps) at some point. See #2316 and #4737.

[MajorMcDoom]

I would probably automatically do this when you load a new sound into the array. Check for other existing audio files that haven't been loaded yet with an incrementing number suffix (with various common separators), and load them automatically after the newly loaded sound.

I think that would be a not-predictable consequence based on user intent. In the best case it's a pleasant surprise, and in the worst case it does something unnecessary and interferes with an intended precise operation. Either way, it would be a surprise, which isn't a good idea for UX interactions.

A button to explicitly do this is simple, clear, and predictable - it does not require arbitrary learned contextual rules like only incrementing from the number you drag in.

Additionally, even without the button, if we support dragging multiple files in, it is already very easy (a shift-click) for the user to just select all the relevant files and drag them in. They can also pick specific ones or exclude specific ones. There is no need to guess on the user's behalf which files should be "auto included" based on a single file addition.

For instance, loading sand0.ogg would check for sand1.ogg, and sand2.ogg if sand1.ogg exists, and so on. The number ordering needs to be contiguous for this to work, but it can start from any number. Handling leading zeroes might be difficult, but it may not be worth doing as you'll rarely have more than 10 random variations of a sound (if starting from 0).

I don't think handling leading zeroes is that difficult. We just have to match all files which have a prefix, and the rest (after trimming off the prefix) consists of only numeric characters or dash or underscore or period.

[Calinou]

A button to explicitly do this is simple, clear, and predictable - it does not require arbitrary learned contextual rules like only incrementing from the number you drag in.

One issue I have with adding a dedicated button for this workflow is that it would separate itself from other workflows in the inspector. I don't expect every inspector to have to implement its own button (which requires custom code) just because it needs some kind of autofill functionality, so I would rather have it happen automatically without the user needing to think about it.

I'm pretty sure this will be helpful 99% of the time, and in the 1% of the time it's an hindrance, you can always unload the extraneous resources that were loaded in manually. To me, this is better than having to go through a slow process 100% of the time 🙂

Either way, if multiple file selection is implemented, there probably won't be too much of a need for this feature in the first place. My observation was mostly in the context of material editing, where I've done thousands of clicks over the years that could be saved by having autofill functionality.

[MajorMcDoom]

A button to explicitly do this is simple, clear, and predictable - it does not require arbitrary learned contextual rules like only incrementing from the number you drag in.

One issue I have with adding a dedicated button for this workflow is that it would separate itself from other workflows in the inspector. I don't expect every inspector to have to implement its own button (which requires custom code) just because it needs some kind of autofill functionality, so I would rather have it happen automatically without the user needing to think about it.

I'm pretty sure this will be helpful 99% of the time, and in the 1% of the time it's an hindrance, you can always unload the extraneous resources that were loaded in manually. To me, this is better than having to go through a slow process 100% of the time 🙂

Either way, if multiple file selection is implemented, there probably won't be too much of a need for this feature in the first place. My observation was mostly in the context of material editing, where I've done thousands of clicks over the years that could be saved by having autofill functionality.

I see, yes. If we're talking about the button, then I agree, it may be more bulk than needed, especially if the multi-drag is implemented. Hence why I offered them as alternatives. I think with multi-drag support that doesn't need to target a specific stream slot, you already have precise control plus the ability to perform bulk operations quickly, making automation of any kind way less necessary than it is now.

I can definitely see material texture auto-detection based on convention as a more compelling case for the kind of interaction you're taking about though.