How do I choose a random audio without a loop?

Help and Feedback Scripting Support
#1

Hello, I am wondering how I can make a random audio play without using a loop. Because they can take up a lot of memory and fps.

The inefficient way:

while true do
	local RandomChoice = Audios[math.random(1,#Audios)]
	RandomChoice:Play()
    wait(RandomChoice.TimeLength)
end

The way I want to make it:

if RandomChoice.Completed then
-- Plays a different sound
2 Likes
#2

Try using: RandomChoice.Ended:Wait()

— Play random sound

function playSounds()
    local RandomChoice = Audios[math.random(1,#Audios)]
	RandomChoice:Play()
    RandomChoice.Ended:Wait()
    playSounds()
end

playSounds()

This should hopefully make a recursive function acting as a loop, but only calling itself after the audio ends

4 Likes
#3

But then I would have to make a loop to constantly call the function. Unless I’m missing something. Also I don’t think you can call functions inside of them.

#4

No, the function will automatically call itself when it’s time to play the next audio, it’s called a recursive function

1 Like
#5

If this works then it would be much more efficient then running a while loop forever.

#6

The code he gave you is what you’re looking for, and if you need an explanation - here it is :

Here, we define the function - nothing new.

function playSounds()

end

Here, we’re choosing a random audio [out of all the audios we have in the Audios table].

local RandomChoice = Audios[math.random(1,#Audios)]

Here,we’re playing the chosen sound.

RandomChoice:Play()

Here, we’re calling an ‘Ended’ event to be called when the chosen sound is over.

RandomChoice.Ended:Wait()

And here, we’re calling the function inside itself, which might look bizzare, but this way - the function will return itself , as @domboss37 said - it’s a recursive function.

Lastly, we call the function here, and it’d start the process

playSounds()
#7

To be honest this question is based on a misconception. Loops aren’t slow. Computers run on loops. Loops are actually really fast.

Sometimes loops appear slow. To show you why let’s make a very simple game loop.

while true do
    physics()
    userCode()
    drawPicture()
end

This is a very simple loop that will run the game. The frame rate you are going to get in this game is determined by how long it takes for the game to reach and complete drawPicture. Of course rendering is super complicated at times and so is physics. So to make everything easier we aren’t going to handle any of that. Instead we will write userCode. Now let’s put this in

local userCode = function()
    while true do
        print("a")
    end
end

After running that, the application will stop responding. This is because that code never stops to allow the rest of the code (like the drawPicture function) to run. Though the game is still running, it’s essentially useless now since you will never see an update.

But if your loop only went a handful of times instead of forever, the game would be fine. Additionally if you could somehow tell your loop to pause itself so the rest of the code could run, the game would still run fine as well. This second option is basically what wait(x) is doing. It’s letting Roblox know your code is ok to stop for x seconds so it can do the stuff it needs to do like rendering and physics.

So an infinite loop will break the game if you don’t yield. Since you have a wait though, there is no issue.

Also when you consider the recursive function that you accepted as your answer, it’s just a loop with extra steps. The most you could optimize that function to behind the scenes is going to be the same as a while loop. So you will save no time. In fact, depending on if and how it’s optimized, it might be worse. It can’t be better though.

Also if you are wondering why events are generally better to use, it’s because Roblox is determining somewhere in its game loop when to run the code you connected. So in the end connections are loops too, it’s just taking advantage of information roblox already has and only running your code when needed.

Though I would recommend styling your wait like @domboss37 does so you’re waiting for the audio to end based on when it decides it’s over. It will just make your code more resilient. For example if you were to change the playback speed at all, your current code would break, but the event:Wait() code would still work flawlessly.

tldr; Your code is fine how it is originally. It’s just a misunderstanding causing this question.

1 Like
#8

I 100% agree with you on this one, the only reason I mentioned a recursive function was because OP just wanted essentially a loop, with out looking like a loop (if that makes sense)

2 Likes