Why is there a 'playdate->sound->sampleplayer->setRate(...)' when to play a sound via 'playdate->sound->sampleplayer->play(..., float rate)' you have to specify the rate?
It seems that 'setRate' is useless?
Put another way... why is the rate parameter for the Lua SDK sampleplayer:play(...) optional when for the C SDK sampleplayer->play(...) it's mandatory? Is there a value for the rate specified for sampleplayer->play(...) that means 'use the already set rate'?
It's so you can change the rate (pitch) at any time.
I use it to change the sound according to a value from the current game state. I never specify the rate when I do the initial loading. In Lua rate is an optional parameter on the play command.
For example you could have a single footstep sound and use it for different characters with different properties. By changing the rate (pitch) their footsteps would sound different. And if they're walking on different surfaces or at different speeds you could change the rate for those, too.
- slow movement = low rate
- fast movement = high rate
- large object = low rate
- small object = high rate
- soft surface = low rate
- hard surface = high rate
By tying the rate (pitch) to a value that is constantly changing you can make a single sound effect go a long way!
There's something I'm missing here.
Yes, I understand that setting the rate can give you different effects. That's what I use it for, too .
My situation... I'm porting a game I wrote last year from Lua to C, the Lua code loads all the sounds and sets their rates up front, then I just sound:play(1) when I want one to go off. So, in C I did the same thing. But now in C to play one I have to also specify a rate (mandatory) on invocation, so what good is setting the rate up front? Seems pointless.
Ah, sorry, I missed that you were talking about C. In that case I can't help
This is the missing link. I'm using C. How is the rate optional?
Edit: we cross-posted at the same moment
I still have no idea what 'setRate' is for in the C API (and it's a bit of a PITA to have to specify it all the time at the point of invocation ).
Ok, digging through the header files... I can kludge this by doing:
playdate->sound->sampleplayer->play(mysound, 1, playdate->sound->sampleplayer->getRate(mysound));
Seems very wrong to me, but I can wrap that up in a function and make it less fugly.
Still... what am I missing?
It's like that because you can change the rate of the sampleplayer with setRate() while the sample is playing!
With something like this, using a sufficiently long sample (done in Lua because I know the syntax offhand a little better than for C):
local testRate = 1
local isPlaying = false
if (isPlaying == false) then
isPlaying = true
testRate -= 0.02
...you can hear the sound slow down, then eventually reverse faster and faster. You could use this to "travel" through samples or just for neat audio effects.
I agree that it's annoying to have to specify the rate every time, and it is certainly makes things more cluttered to have to reference the current rate each time. It's one of the downfalls of using C (defining optional arguments in functions is more complex, so it's not always done). I also think defining a shortcut function is the best way to work with this limitation.
playdate->sound->sampleplayer->play(mysound, 1, 1);
You can pass 1, it's there to provide an initial rate like the Lua counterpart. I haven't tested but I think you can play it multiple times with different rates (?)
I'll just wrap the get/set rate part in a function and call it a day.