I would like to be able to create a music crossfade in an adventure map that I'm creating. The idea is to overlap two versions of the same song, one the "chill" version, another the "fight" version, and when a player gets in a fight with enemies, crossfade over to the fight version, as well as being able to nicely fade out music in general.

My original idea was to have 2 invisible armor stands act as the source for each of the tracks, then move the armor stands away/towards the player, slowly fading in/out each track. This actually works pretty well, but when the crossfade is over, I make the armor stand emitting the now faded-in song ride the player, so it just sticks with them. This also works, and when the player is running straight ahead, it sounds correct, but when the player strafes, it does like a sawtooth effect on the panning, and is REALLY distracting sounding. Any other ideas for a way to make this kind of thing work?

I've also tried messing with setting the attenuation_distance very high in the resource pack, but that doesn't change anything, though I suspect that it's because it only affects certain entity types anyways.

I am writing a server plugin, so I can do anything available in bukkit/paper, and am even perfectly fine doing things with ProtocolLib or other version specific hacks, but I am not expecting players to have to download a client side mod for this map.

  • 1
    That is already a pretty smart method, I would have thought that this was impossible. Considering that endermen and phantoms continue their annoying screams long after their deaths, I thought Minecraft just played all of the sound at its starting point. Maybe you could only do the travelling armour stands thing during the fade and otherwise play the music in a global way. You could cut the track into little segments and the fade could only start with the next segment. But this would lead to issues as soon as there is the slightest bit of lag in either server or client or their connection. Commented Apr 1 at 1:52
  • Actually /stopsound exists, so most of the time, the music can just be one piece and play globally and then there could be many variations of the fade, each with a different starting point. Then you would not even need the armour stand trick at all anymore. And after the fade ends, you play the other music globally, but you also need many variations with different starting points. Or, since it goes both directions and everything needs variants, include the fade in the variants of both tracks. Does that idea work? Commented Apr 1 at 1:56
  • 1
    Unfortunately that has issues too. I tried something like that in my last map, where the boss music looped the middle segment, and cut at a musically coherent spot to the outro, but due to client-server lag it never sounded right. Having that problem everywhere would be worse.
    – LadyCailin
    Commented Apr 1 at 8:39

1 Answer 1


So, I ended up with a situation that works good enough for my purposes, but still has some drawbacks. Essentially, I place 4 entities (item displays) at the cardinal directions of the player, 10 blocks out, 5 blocks above, and start the music with each of the 4 in the same tick. This seems to reliably sync up the music. Then, every so often (4 times a second) I move the entities into the correct location again, so they are again 10 blocks out, 5 blocks up. This has a strange effect when the player spins around quickly, but actually, that strange effect happens with the rain and other sounds too, so I can live with that.

For the crossfade, this is simple, and just does the same as , I have the other set of 4 entities far enough away from the player that they can't hear them, but then move the first song's "speakers" down, while moving the fade in song's speakers up. This has a very nice fade effect, and while it is a bit jumpy, I could fix that with a higher frame rate.

Speaking of frame rates, because my "adjust position" logic only runs every .20 seconds, this method is pretty bad with flight and falling from high distances. However, you can turn the volume up, and this works well enough, since this decreases the amount of attenuation per unit moved. However, this means that the distance of the "fade out" state needs to be higher before it drops to 0. If you set that too high, this introduces a new problem with the "stowed away" speakers, which is that if the player gets too far away, they stop playing music, presumably because the client unloads them, and so also forgets that they were playing music. Thus, I have settled on just living with the fact that if a player moves fast enough, this system gets a bit janky. I may continue to improve on this later.

All in all though, this works surprisingly well, though I am excited to see how it performs with load testing.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .