Oolite Bulletins

I've just installed my new speaker system. Then I started Flight Gear, turned up the bass and started up the radial engines of a DC-3.

Then I noticed, that Oolite is quiet. Very quiet. Too quiet!

I know that space is quiet, but I'm not sitting in space but in a metal box filled with complex technology! I think I've seen a Oolite video containing sound effects for at least torus drive and/or injectors. Are there any sound OXPs that can be recommended?

The sound effects in  BGS are pretty good - background noises, injector sounds, muzak in stations, etc.
I believe you can use the sounds without the screens if you so wish too.

I've watched the video linked on the wiki page, and the sounds are actually those I remember from the other video I mentioned. It says it can be configured, so this is perhaps what I'm looking for. I've overlooked it in the OXP list, probably because of the background pictures that seem to be the main part of this OXP.

The indecipherable comms chatter in the aegis becomes rather repetitive - but nevertheless, it adds oodles of ambience.

I think I will try to deactivate this because Comms Pack A adds more than enough "chatter". I'm more interested in the "technical" sounds.

It's ship-to-ship audio chatter within the aegis, not screen messages as in Comms Pack - but BGS is fully configurable.

I'll definitely have a look at it when I'm done with my current OXP project!

Sadly it's not really what I'm looking for, and I already feared it when I watched the videos: There seems to be no possibility to adapt sounds to an in-game value like speed.

The BGS OXP has a constant background engine sound. Basically this is what I was looking for, but this sound is always the same. It is switched off when speed goes to zero and switched on when starting to move again. It then remains the same for all speeds. Of course we don't know how Oolite engines and power generators work and if rotating parts are involved, but realistically the sound should start with a low "engine standby" frequency that is getting higher when accelerating. In the ooniverse, where there is no thrust, the frequency (and perhaps the volume too) should depend on ship speed.

The OXP uses additional sound files to create accelerating and decelerating sounds. But they don't "fit" the actual changes of speed, they are always the same. The acceleration sound is even played two times until my Python reaches it's top speed, but that's probably only my (faster) Python variant...

I'm no sound expert, and I can't even say if it is possible with modern audio cards, but on the C-64 it was possible to directly manipulate the sound chip, so you could easily change frequency or volume depending on some in-game value. Oolite and probably most other games just play little sound files (wav, mp3, ogg), one for each effect. Creating something like a continuous propeller engine sound probably involves repeating one or more very short sound effects over and over again with varying frequency (that's basically how the sound is created in reality). And I have no idea how a whining turbine engine sound could be created - it would be more fitting for a space ship!

The BGS OXP has a constant background engine sound. Basically this is what I was looking for, but this sound is always the same. It is switched off when speed goes to zero and switched on when starting to move again. It then remains the same for all speeds. Of course we don't know how Oolite engines and power generators work and if rotating parts are involved, but realistically the sound should start with a low "engine standby" frequency that is getting higher when accelerating. In the ooniverse, where there is no thrust, the frequency (and perhaps the volume too) should depend on ship speed.

This is due the way BGS works. It basically is a sample play engine. So yes it uses fixed samples played in loops. I made that engine sound and I think I can do better. But you are talking about a form of in game sample manipulation. That is not possible in the current BGS implementation. I think Svengali can explain it better than me because he wrote all the code for the BGS project.

It would be nice if we could have a changeable engine sound even if it takes more than one sample. I make also engine sounds for Trainz and they use 8 samples to speed up and 8 samples to speed down in that game.

I haven't installed the OXP nor looked into it, but if this here is just about playing different sound samples and how highly the background humming is pitched in relation to the current speed, how about dividing the speed into, let's say, 5 regions. (every 20%-step of full speed) Each speed region would have it's own humming sound and if you accelerate or decelerate from one region into the other a short interim sample is played with the higher or lower becoming frequency. The length of the samples could be matched to the rate of acceleration so that it sounds like one nearly fluently higher or lower getting sound if you go from 0 to 100% or step onto the brakes. And when speeding into one speed region and then back again (from 19% to 22% and than quickly back to 17%) just stop one sample and do the other right starting from the high frequency. This might look like an ugly Idea, but I imagine, that it actually sounds better than thought.

I was thinking in the same direction. To avoid "steps" in the sound, you could work with 50 or perhaps even 100 different sounds, one for each percent. This wouldn't make the OXP too big - the files would be small, and other OXPs are full of background pictures and textures.

I don't know if there is an event like "speed changed", but if there is, it could be used to start the correct sound file (and end the old one). There could be a problem with this operation being too slow, but I think, acceleration (speed of speed change) is too fast anyhow.

This would be much easier if the speed of sound replay could be changed. In this case, the same file could be played with 50 or 100 different speeds.

Fritz wrote:

This would be much easier if the speed of sound replay could be changed. In this case, the same file could be played with 50 or 100 different speeds.

Yeah, but as pagroove already said, that would be in game sample manipulation.

And there is speed(player.ship.speed) and maxSpeed(player.ship.maxSpeed)
Wiki:Oolite_JavaScript_Reference:_Ship#speed
you could use both values with the Dreisatz (Hab jetzt keinen Bock das nachzuschlagen. )

About the 100 sound samples...It's less about the file size but more about processing speed. You would have to start new sound processes every few milliseconds. This will come with a huge performance breakdown, I can imagine. Even if you only start a new sample ever 100ms, that's still a bit much.

Please tell us how well it's going. ^^ If you have any questions, just post them.


Edit:

I don't know if there is an event like "speed changed"

Ahhh, right. You do need an event for when the speed is changed...Just having a timer too check every 10ms is a bit much.

I'm not planning to try to program anything like this at the moment, but I just had a look at Oolite JavaScript Reference: SoundSource. It seems that volume can be changed easily, and I assume it can be done while a sound is playing. So one solution to optimise the background engine sound could be to make it louder with increasing speed. And if the SoundSource object had a property "playbackSpeed", the problem would be solved at least at this basic level. The question is if this would be easy to implement.

Fritz wrote:

I'm not planning to try to program anything like this at the moment,

Too bad.

Back to the event needed. I didn't find anything usable, net even under Oolite JavaScript Reference: ship script event handlers. But there is always some way.

I'm currently working on two OXPs, sooo I might actually look into it later, but not now. If somebody wants to take on it, feel free.

Check [wiki]Engine Sound[/wiki] OXP in the Ambience category, I just made what currently is possible.

In general, core change requests only slowly arrive into the stable Oolite so I think first we should try to do what is possible in js - I found acceptable workarounds many times so far.