I was wondering too, I’ve seen the documentation for it and I’m quite excited for the changes. Especially for the multiple 3D sources of sound, and the new “AudioAnalyzer” instance which should make audio visualizations way more interesting. I’ve already seen your video on it on an earlier release note.
On another note to staff; I was wondering if this would replace existing Sound instances by deprecation, or if both methods would still be available? Also, will there be more effects/deeper controls on audio effects in the future?
Yep! I got to try it and it’s honestly pretty cool watching others code in real-time with their labels flying around. I didn’t get to see how undo/redo works though so I’m interested to try it again once it becomes a Beta feature.
If you’re talking about the Script Profiler fix, there’s nothing internal about it, you can use it from the Developer Console and all the functions mentioned are now displayed.
It’s not like the existence of upcoming AudioAnalyzer instance is a secret.
The AudioPlayer is similar to a sound, however it sends a audio stream when wired to a audio class with an input pin. The audioplayer basically has every property of Sound except for a few such as volume and playbackloudness (I assume could be added in the future when it’s released fully). It also has :Play() and :Stop() as its only functions. Playing a audioplayer by itself will not project audio or project audio in the 3D space (AudioEmitters do that), it will only project a audio stream.
I wouldn’t call AudioPlayer a advanced sound object, but rather the base of what you connect it with using Wires.
Here’s how it worked with my visualizer.
AudioPlayer → Wire → AudioDeviceOutput: Sends a audio stream from the AudioPlayer to the output audio devices such as headphones, etc.
AudioPlayer → Wire → AudioAnalyzer: Analyzes each audio buffer and information is receivable through :GetSpectrum() which returns a frequency spectrum through a table of numbers
There’s a lot more you can do with Wire but the point of the new Audio classes is that it allows you to customize where your audio outputs, what inputs and what and where the effects are (e.g fade)
It’s the same validation that is shown in the publish menu. For instance, if you import a character with an arm too big, or bad vertices, or whatever else. Only our defined automated validations, nothing potentially subjective (like things that look like accessories on your body).
The idea is to surface avatars we know we won’t accept as early as possible.
That’s more commonly called Hot Module Reloading (especially in the web development community), and is possible in Roblox through libraries like Rewire. Anything like this that makes iteration faster is a big win for developers if it allows us to write, test, and debug code more efficiently, and if possible I’d love to see something like it integrated into Studio as well.
How can you have a bad experience with ProtectedString when it is not even a legal type? It is only used in script sources. You cannot define a string as ProtectedString as it’s a locked property type.
Exciting, very similar to VSC’s live share feature which I quite like. So happy that Roblox is embracing multi-worker projects and studios and this will make code reviewing for junior developers much easier to do as they can be critiqued and watched live.