Bring back indoor music. It was charming and great.

[NotJimmy97]

A bit torn on the matter. Will consider.

I hope that "but mp3 files are too large" is not a reason for us not having music.

It is, though. Take, for example, when MM added music to Salem, which made the initial download grow from ~40 MB to ~160 MB.

Which is also the answer to NotJimmy97.

That's a fair answer. However, if any additional music is added, I think it might as well be the house song, since I remember it from legacy H&H as one of my favorite little details.

[loftar]

This applies to all games. But many games still have music of somekind.

True, but Haven is also unlike many games in that you more commonly have it running in the background, switching to and from it, which makes it far more reasonable for you to listen to "other music".

[dafels]

a sick soundtrack for every biome! Go loftar go!!

[loftar]

a sick soundtrack for every biome! Go loftar go!!

Having different ambient sounds and music for each terrain would be one of those really, really nice things, for sure. :)

[Granger]

One technical reason to not bring back the music in its "current" condition is that it uses the MIDI system to play it back, which is unreliable to say the least. I have a background project to write a software-MIDI "renderer" which would fix those problems, but it's obviously not my absolutely highest priority.

I suggest you ignore NIH-syndrome for this and integrate http://timidity.sourceforge.net/ into the client instead. Or render the current tracks to mp3/ogg and cache them on the client.

[dafels]

a sick soundtrack for every biome! Go loftar go!!

Having different ambient sounds and music for each terrain would be one of those really, really nice things, for sure.

yeah, the moore soundtrack is really gr8

[loftar]

I suggest you ignore NIH-syndrome for this and integrate http://timidity.sourceforge.net/ into the client instead.

I'm not sure writing JNI wrappers for Timidity is less work, to be honest.

Or render the current tracks to mp3/ogg and cache them on the client.

If by this you mean not including them in the initial download, then the problem is that the time required to download them on-demand can be quite excessive when other resources are needed as well.

[Granger]

I thought more about including a platform specific version plus a sound font into the initial download and then use the command line version to render a wav on demand in a thread with a pipe.

For mp3/ogg fetch them from the server with low priority (to not delay the important stuff) and stream them as soon as enough data has arrived (cache them locally too).

The latter method is better as you don't limit yourself to midi files.

Just planting seeds...

[loftar]

I thought more about including a platform specific version plus a sound font into the initial download and then use the command line version to render a wav on demand in a thread with a pipe.

Are you suggesting I include pre-built Timidity executables for various architectures and platforms, unpack them somewhere, and launch them as external processes? Even JNI wrappers seem nicer than that. MIDI isn't so complicated that it's worth going to such lengths to avoid implementing it. I want to believe that I'm just misunderstanding you and that you're not seriously suggesting that.

For mp3/ogg fetch them from the server with low priority (to not delay the important stuff) and stream them as soon as enough data has arrived (cache them locally too).

I've considered such solutions, but given all the caveats -- it would have to be built outside the current resource system since that system doesn't support streaming, which would also entail some reasonable way to refer to such files, and also try (and tail) to handle fluctuations in bandwidth, falling back somehow when enough bandwidth is simply not available, and whatnot -- it is not obviously worth it. That is what has caused me to gravitate instead towards some MIDI+SF and/or MOD-file implementation.

[Granger]

I thought more about including a platform specific version plus a sound font into the initial download and then use the command line version to render a wav on demand in a thread with a pipe.

Are you suggesting I include pre-built Timidity executables for various architectures and platforms, unpack them somewhere, and launch them as external processes? Even JNI wrappers seem nicer than that. MIDI isn't so complicated that it's worth going to such lengths to avoid implementing it. I want to believe that I'm just misunderstanding you and that you're not seriously suggesting that.

Why not? At least it gets the job done (render a MIDI to something that can be stuffed into an audio output stream by the client), KISS principle has its merit at times. You could view it as an external decompressor library if it helps you to feel better about it.

I learned over the years that, at times, absurd suggestions trigger new and interesting thoughts in others - you could just as well take my comment as a practical application

For mp3/ogg fetch them from the server with low priority (to not delay the important stuff) and stream them as soon as enough data has arrived (cache them locally too).

I've considered such solutions, but given all the caveats -- it would have to be built outside the current resource system since that system doesn't support streaming, which would also entail some reasonable way to refer to such files, and also try (and tail) to handle fluctuations in bandwidth, falling back somehow when enough bandwidth is simply not available, and whatnot -- it is not obviously worth it. That is what has caused me to gravitate instead towards some MIDI+SF and/or MOD-file implementation.

MP3/OGG has the upside that you're not limited to MIDI or a certain tracker, so procurement of music (or an artist to create it for you) will be easier when your source is a simple WAV.

Regarding the handling of loading/streaming: Why not just fetch them as any other resource then (as long as it won't block important stuff)? First play will be delayed by loading time, but that won't hurt as it is 'only' background music and the client will cache them all over time anyway.

While at comments about music: could you please give us the option to, additional to a general music volume slider, mute individual tracks? While some may like most or all of them, others might hate a certain track enough to never wanting to hear it again... it would be a shame if these would have to resort to muting the music completely.