Plugins should not require a dock widget to play sounds

Plugins cannot play sounds that are not a descendant of a DockWidgetPluginGui. When Play() is called on a sound, it will set the Playing property to true, but it will not play any sound. This behavior negatively impacts developers who create plugins that don’t use widgets (as widgets do not work with UserInputService) and need to play an audible sound. Developers are then forced to create a clunky workaround of creating a ghost widget to parent and play sounds from. There is no point in restricting plugin access to play audio.


Hey FartedTooHard; I feel your pain, and have run into this as well. Several years ago we made it so that Sound.TimePosition doesn’t advance in the studio editor – so even if you set .Playing to True, the Sound doesn’t actually play until you enter Play-mode.
Now, many developers use workflows that depend on this – for example, setting .Playing and .Looped to True in the editor to make a sound start playing and looping as soon as it spawns & loads.

If a Sound is a descendant of a PluginGui, we can be reasonably sure that it’s only intended for plugin use, so we added an exception to let TimePosition advance anyway. But this is definitely not a great, general solution; it’s more like a workaround that we added to make plugin development slightly less restrictive.

Making substantial changes to Sound without breaking someone’s workflow is really tricky; however, we announced a new AudioPlayer instance at RDC! This API is not officially released yet, but AudioPlayers (and many of the other new instances) are already enabled.
Unlike Sounds, AudioPlayers are fully-playable in the studio editor – since it’s a brand new instance, we didn’t have to worry about unintended breakage, and their behavior should be much friendlier to plugins


I’ve played around with AudioPlayer already by messing with some internal flags. Im curious what exactly would be the output source here that could be wired into.

AudioDeviceOutput is the final output, so stuff that’s wired to one of those will be heard. To play and hear an AudioPlayer, you could set up something like AudioPlayerWireAudioDeviceOutput.

But, you could also wire the audio to other stuff along the way; for example:

Or in the case of 3d spatial audio:
AudioPlayerWireAudioEmitter & AudioListenerWireAudioDeviceOutput

1 Like

does audio device input work yet or is that still a wip?

That one is currently disabled; you can create them, but they make no sound (yet) – we’ll update the docs (currently blank) and make a proper announcement once all of the new instances are ready to use

1 Like