Been busy working on a new prototype, I've moved the other's into a new bitbucket respository: (https://bitbucket.org/magurp244/audio-code/downloads)

I've uploaded a new version of my side scroller with stereo proximity volume effects for terrain objects, in this case water to the left and right. Fixed a few bugs with the audio renderer, and found a few more, heh. In this case it seems to be having a pitch issue on varying draw speeds, though i've capped it at usable levels.

I've also uploaded my second prototype that got arbitrarily flagged earlier for anyone that wants to give it a spin, a 3D FPS. I don't have much experience in 3D, but I managed to modify an open sourced Minecraft Clone to render a simulated Depthmap and embedded my audio-renderer. Have a few idea's on how I can refine it, but again not much experience with 3D.

Hmm, the difference in stereo is negligable, its hard to tell where anything is spacially. I'm going to assume that stomping sound is an enemy? The volume and stereo position of the stomping sound doesn't seem to change at all, so its difficult to tell what the proximity is to the player.

What recording software are you using? Looking at them in Audacity it looks like the two channels are vitually identical.

Thats... Strange. Do you mean the volume bars are different playing the recorded raw output or playing in the sound engine itself?

I've been running a few tests in my side scroller trying to replicate it. I ended up stripping out all the tiles except two and messing with the sound positioning for awhile before I got a clear stereo panning effect in the output, still a little twacked on positioning though. I've uploaded the recording to my repository if you want to listen to it, walking between two points.

Wierd though, if there's a slope to your right and a flat surface to the left, or moving between two points there should be some kind of stereo effect in the recording. Maybe you could try recording the output through another program like Audacity instead to see if theres an issue with how its being logged, though you'll have to change audacity's Preferences: Recording Device from Mono-Mix to Stereo-Mix.

In Audacity.

Note that the UV meters showing different values doesn't mean much, the overload probably kills any possible perception the brain could try to figure out. I mean, when you play the same sound over both speakers the brain interpretes it as being in the center, not as being two separate sounds...

I think there's still such a massive sound overload that it basically nullifies any stereo effect you could hear. Also for some reason it seems slopes are less notorious than it used to be in the early tests I made (and this is noticeable even from mono) so I definitely need to do something about the viewport.

Honestly now I wish I had just stuck to the zoomed viewport but the problem is that people had trouble seeing the enemies before it was too late (they're still easier to notice when you're sighted, after all).

I tried but I got garbage for some reason. Probably PulseAudio messed up and I wasn't in the mood to fix it (restarting PulseAudio solves the issue, but... lazy).

That's because everything can be made out of sine waves. How well you can recreate the relevant harmonics is a different story altogether.

EDIT: WTF checking that test recording, I can perceive the stereo even with the laptop's speakers, I think this is the first time I can perceive stereo without headphones.

Well it means I shouldn't need headphones to hear stereo for sure... so if I can't hear stereo with my sonar it means its stereo is horrible.

Later I'll try the corner idea I mentioned earlier, maybe it reduces overload enough to make this feasible. Just a dumb question though, how do I mark where slopes start or end? Wondering if I should use blinking to distinguish the different parts of the silhouette.

I was considering this:

Gap = fast blink
Slope = slow blink
Ceiling = no blink

I was wondering about how to mark the direction of the slope, but maybe context is enough. Also I need a way to easily mark the boundaries of the level... also what to do if there's a wall where the top is higher than the viewport?

I've just finished packing my new Demo, AudioRTS! Been working on it all month with all sorts of features, i've uploaded it and a recording of the demo to my repository for anyone who wants to try it out or listen to it. I'm interested in any feedback or questions anyone has. Quick rundown of some of its features:

-The demo features a top-down grid perspective of the environment, objects like buildings, resources, units, and terrain all have unique sounds to identify them. It runs at a resolution of 640 by 480 with over 300, 32 by 32 tiles.

-It uses a Proximity Mouse system, with the position of the mouse determined by 3D stereo panning and pitch. The closer objects are to the mouse, the louder their unique identifying sound is, up to two tiles away in a radius around the mouse.

-There are at the moment two controllable units and three buildings, you can't build anything, but you can harvest resources and blow some stuff up.

-The demo also features a functional Minimap. Rendering all sorts of data in a sonified image tends to create too much conflicting information, so instead the minimap is divided into a series of "slices" that each render only one kind of information. For example, press F1 and it will draw an image showing ONLY the positions of friendly units, F2 an image of only enemies, F3 only resources, F4 terrain obsticals, etc.

Sort of, I suppose. In many respects its not much different from flashing blocks already, the only difference being they move and/or change pitch. Been running a few tests with the idea using the same tone at different pitches, thinking maybe using different kinds of tones for each slope or direction they "flow" might be better. Uploaded the recording to my repository, first half is with a higher slope on the left moving down, and another on the right moving to the bottom corner, second half is a slope in the lower left moving up, and the one on the right still moving down. Seems to have too much of a bleed effect at the moment.

Maybe another way to help cut down on noise would be to render only the side of the screen the players character is facing in the respective left/right audio channel? That way you wouldn't get the interference from the opposite side, though you could still play enemy sounds and such.

Sorry, I didn't mean to suggest you should use different tones, i'm just looking at different approaches on my end.

I realize that rendering only half the screen could potentially be problematic (though I did say you could still play enemy sounds regardless in either direction), you have to keep in mind that it would likely take a fraction of a second for the player to turn around and view the other side of the screen, if it helps cut down on interference and makes the scene more readable it may be worth considering, but thats up to you.

Hmm, so a Gap is a constant fast blink, a Slope is a constant slow blink. What about a blink that slowly shifts from fast to slow? Or a different pattern like morse code? Well, morse code may be going abit far.

New attempt:
http://sik.titandemo.de/.junk/audio3.ogg

This is definitely much better. At least now I can tell apart things even though I'm not using headphones. Still needs improvement I suppose, but I want to see if people can start getting an idea of what's going on. (also I noticed that pretty much every sound effect is happening where the player is so far, making 3D positioning for them useless...)

Amusingly at this point it barely even resembles vOICe at all.

The volume balance of the objects was completely off after the new algorithm so not surprising, they were barely hearable at all. Now I tweaked them back in. Moreover, now they're represented by a single point, which indicates the closer part of their silhouette. This was done to reduce sound overload... honestly there's still a lot of overload though.

Current attempt so far:
http://sik.titandemo.de/.junk/audio4.ogg

I really can't think on a way to get rid of the overloading =/ Also later I'll need to think on a way to do the conveyor belts (which will need to be marked in a way that makes it clear they're moving), and come up with a better way to represent pits. Also, I noticed that inner corners from rooms don't make sound if the ceiling is too high (because they lack a mark to represent them).

The problem with this is that extra sound effects costs money to get done, the sounds from the sonar are generated on the fly instead