Pause and stop controls now appear in the corner of the window when an AudioStream is selected:

Because the stream is played through the Quick Open dialog, not the node whose property is being set, the preview of the stream will (or, should) not include any extra effects added by the node or audio buses.

Shouldn't it play using the edited node though? When you preview a texture for a sprite, it displays with proper materials and color, so the same should apply to audio players I think.

I could give that a try! My concern with it was that (as far as I could think) it would involve enabling the AudioStreamPlayer, AudioStreamPlayer2D, or AudioStreamPlayer3D's playing property in addition to changing the actual stream property, for those most basic cases. I'm not sure if there could be some unintended side effects of that?

In more complex cases, where for example a user has an exported AudioStream variable that they want to load into a player at runtime, I don't think there would be a way for the Quick Load dialog to detect where/how it should play the preview, so that it has the correct effects and such applied.

I suppose then we could have it run two ways like this?

• If the property being modified is the stream of an AudioStreamPlayer(2D/3D), enable its playing property so that you hear the stream with appropriate effects applied. Once the user confirms the selection, disable playing.
• If the property being modified is not the stream on an AudioStreamPlayer(2D/3D), take the current approach of playing the preview through the Quick Load dialog itself.

I've applied the approach I described in my previous comment. If the user is editing an AudioStreamPlayer(2D/3D).stream property, then the Instant Preview uses the playing and stream_paused properties so that you hear the stream with the bus effects and such applied. For other properties of type AudioStream, the Instant Preview uses its own internal AudioStreamPlayer so you hear the sound "directly".

I think this is a great addition. Just yesterday, I was kind of struggling with the current UX where you have to double-click each audio stream in the file system and then press play in the inspector which felt very cumbersome.

Here's what I noticed though:

1. toggling the "Instant Preview" button does not toggle the visibility of the media controls
2. You have to use down arrow and then up arrow to previvew the first file
3. Pressing spacebar doesn't play / (un)pause the currently highlighted audio stream

Thanks for your feedback! To address each of your concerns:

toggling the "Instant Preview" button does not toggle the visibility of the media controls

That does seem like something it should do. I will add that to the to-do list for this PR 🙂

You have to use down arrow and then up arrow to previvew the first file

This is consistent with how the rest of Quick Load/Instant Preview works. If you try to do QL/IP on a Sprite2D's texture property, the texture highlighted in the window won't be previewed in the scene until the user specifically highlights one. While this behavior could be changed so that opening QL/IP immediately previews the first selection, I think that's something that would be better to discuss in its own proposal and implement in a separate PR.

Pressing spacebar doesn't play / (un)pause the currently highlighted audio stream

This has a tricky conflict with the existing QL window: it interprets a press of the space bar as typing a space into the search at the top. I definitely agree that having a keyboard shortcut to pause/play tracks would be nice, but we'd have to either a) figure out how the QL/IP window should handle a spacebar press in this situation, or b) find another keyboard shortcut that wouldn't conflict with anything.

You could at least show audio controls immediately when an AudioStream is selected (highlighted).

Makes sense, I will try to add that soon alongside showing/hiding them when IP is toggled!

As for the creation of the AudioStreamPlayer and control buttons on-demand, is there a particular benefit this would have (or conversely, a reason why always creating them would have a notable downside)? My thought right now is that if their always being a part of the QL window has a negligible performance cost, it's probably safer to just let them exist quietly and show/hide them as necessary, rather than trying to create them when necessary and needing to always ensure they happen to exist at a given time.

The other edits sound good, I'll try to add those soon too.

As for the creation of the AudioStreamPlayer and control buttons on-demand, is there a particular benefit this would have (or conversely, a reason why always creating them would have a notable downside)?

Well, the benefit is that it makes the QuickOpenDialog lighter. Not all quick open dialogs are going to be used to pick audio streams. Although not sure how many dialogs are out there, I suppose it's not worth it if the code is going to become much more complex.

Working on the following fixes:

• Toggling the Instant Preview switch now shows or hides the controls.
• The controls show up immediately when an AudioStream property is selected.
  • The controls default to a "play" button on the selected AudioStream; clicking it starts playing a preview of the highlighted AudioStream.
• When a preview is playing and Instant Preview is toggled off, the preview is stopped. (To reduce code repetition, I'm probably going to need some helper methods that divert a single call for playing/pausing/etc to the correct ASP.)

While working on this, I discovered a bug with IP that I'll file shortly and then hopefully work on a fix for. If the QL window is opened when IP is disabled, then IP is enabled and another resource is selected, the preview will not take effect. Only when a second resource is selected will the preview update. (This seems to be unrelated to the audio in IP, so I won't be including it in this PR.)