A game where the tempo of the music can temporarily change based on player actions, like the speed shoes effect in classic Sonic or a puzzle game where the music speeds up when the player is about to top out and lose, before eventually returning to normal (powerup expired, player cleared enough space, etc).
Describe the problem or limitation you are having in your project
When fading between two streams with AudioStreamInteractive, TRANSITION_TO_TIME_SAME_POSITION can be used to jump to the same timestamp in the destination stream, but there's no way to jump to the equivalent beat, which would be at a different timestamp if the songs use different BPM.
Using a Sonic speed shoes-type example, we would want to transition to a version of the song that plays at 1.5x the normal speed at the same logical point in the song. If we're on the 10th bar of the current song, jumping to the same timestamp in the 1.5x speed version would be in the 15th bar, jumping to a completely different point in the song and not achieving the desired illusion that the song started playing faster, and we would experience the inverse of that misalignment when the powerup expires and we switch back to the normal song.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
This feature would allow users to choose to transition to an equivalent beat in the destination song, such that in the example above, it would jump from the 10th bar of the 1x speed file to the 10th bar of the 1.5x speed file, even though those are at different timestamps in the files.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I propose adding a new value in AudioSteamInteractive's TransitionToTime enum, something like TRANSITION_TO_TIME_EQUIVALENT_BEAT, that uses the ratio of the BPMs of the files being transitioned between to convert the playback timestamp in the source stream into the timestamp of the equivalent beat in the destination file. In pseudocode, that could be achieved with something like:
If this enhancement will not be used often, can it be worked around with a few lines of script?
Theoretically you could do all this math and seek around in files manually, but I think it could be more robustly and intuitively done by extending the existing mechanism that already comes very close to doing this.
Is there a reason why this should be core and not an add-on in the asset library?
It's a fairly straightforward enhancement of an existing built-in mechanism and it makes a lot of sense for it to be integrated there.
Describe the project you are working on
A game where the tempo of the music can temporarily change based on player actions, like the speed shoes effect in classic Sonic or a puzzle game where the music speeds up when the player is about to top out and lose, before eventually returning to normal (powerup expired, player cleared enough space, etc).
Describe the problem or limitation you are having in your project
When fading between two streams with AudioStreamInteractive, TRANSITION_TO_TIME_SAME_POSITION can be used to jump to the same timestamp in the destination stream, but there's no way to jump to the equivalent beat, which would be at a different timestamp if the songs use different BPM.
Using a Sonic speed shoes-type example, we would want to transition to a version of the song that plays at 1.5x the normal speed at the same logical point in the song. If we're on the 10th bar of the current song, jumping to the same timestamp in the 1.5x speed version would be in the 15th bar, jumping to a completely different point in the song and not achieving the desired illusion that the song started playing faster, and we would experience the inverse of that misalignment when the powerup expires and we switch back to the normal song.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
This feature would allow users to choose to transition to an equivalent beat in the destination song, such that in the example above, it would jump from the 10th bar of the 1x speed file to the 10th bar of the 1.5x speed file, even though those are at different timestamps in the files.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
I propose adding a new value in AudioSteamInteractive's TransitionToTime enum, something like TRANSITION_TO_TIME_EQUIVALENT_BEAT, that uses the ratio of the BPMs of the files being transitioned between to convert the playback timestamp in the source stream into the timestamp of the equivalent beat in the destination file. In pseudocode, that could be achieved with something like:
target_destination_position = source.get_playback_position() * source.get_bpm() / destination.get_bpm()If this enhancement will not be used often, can it be worked around with a few lines of script?
Theoretically you could do all this math and seek around in files manually, but I think it could be more robustly and intuitively done by extending the existing mechanism that already comes very close to doing this.
Is there a reason why this should be core and not an add-on in the asset library?
It's a fairly straightforward enhancement of an existing built-in mechanism and it makes a lot of sense for it to be integrated there.