TinySound
TinySound copied to clipboard
Change pitch in music and/or sounds
Hi, Is there any way to change pitch of a Music or Sound object in the same way volume or balance is changed? I'm using this library for my project and this would be a great enchantment. Thank you.
https://github.com/philfrei/AudioCue has real time pitch/volume/panning changes. But it lacks ability to unpack compressed audio (you have to decompress .mp3, .ogg, etc., yourself). Might work as an alternative.
Thanks. I have already tested it. I've been trying to play .ogg files with it just for funny and testing. BTW, I love the frog example. Anyway, I just thought there was an "easy" way to change the play speed in TinySound. As I said, this could be a good enchantment for the library.
Neat to learn you know about the frogs! I get very little feedback.
As an example of what would be needed, if you (or someone else) wants to tackle adding frequency shifting to TinySound, see the class: StreamSound.StreamSoundReference
, the method: nextTwoBytes
. The code would have to be rewritten to allow the position
variable to be a float, and linear interpolation done between the data positions on either side. AudioCue
does this in the method 'readFractionalFrame. But it would be a significant fork to add this given that there are many instances of this method, and dependencies that assume an integer value in the
position` variable.
If I understand how Finn has set things up, he streams directly from ogg files using the libraries provided by Tritonus. AudioCue doesn't provide for decoding during playback. Instead, the entire ogg file has to be decoded and loaded into the AudioCue. I wrote an ugly tweak to the vorbis library to do this, for personal use, but am unclear on how and whether to release that code. Vorbis has an intermediate step in the decoding where data is in a normalized float state. That is the same format AudioCue uses internally. So I added some tweaks to intercept and output to a float[] instead of proceeding to convert to bytes and stream.
I am very late to the conversation. Sorry. I'm afraid I probably won't have time to work on this feature. As philfrei pointed out, I've based the entire library around the assumption that the audio data is 16-bit linear PCM, and while the signal processing necessary for this feature probably isn't crazy, it's certainly non-trivial.