Allrighty, I decided to rewrite it all from scratch, and the volume situation seems to be all fine and well.
Pan is acting weird, though.

I added a line to my code that would copy data to the clipboard, and then I pasted it at some specific points of interest.
The results have me quite confused, though they kinda explain what the problem is:

(These first two work as expected)
Listener:
0, 0, 0
Sound source:
-17, 4, 0
Theta: 0
atheta: -0.231090667195897
rtheta: -0.231090667195897
pan: -19.4683433666715
volume: -17.4642486572266
pitch: 0

Listener:
-14, 0, 0
Sound source:
-17, 4, 0
Theta: 0
atheta: -0.927295218001612
rtheta: -0.927295218001612
pan: -12
volume: -5
pitch: 0

(Then things get weird from here)
Listener:
-22, 0, 0
Sound source:
-17, 4, 0
Theta: 0
atheta: 0.674740942223553
rtheta: 0.674740942223553
pan: -15.6173761888606
volume: -11.403124332428
pitch: -2

Listener:
-17, 4, 0
Sound source:
-17, 4, 0
Theta: 0
atheta: 1.5707963267949
rtheta: 1.5707963267949
pan: -0.00000000000000122464679914735
volume: -5
pitch: -2

Pan always seems to have the same sign regardless of the sign of atheta and rtheta. To make things weirder, a sound will switch sides if one passes it y-wise, and the panning works perfectly if one stands still and spins around (changing theta).

Note that the data is copied after the sound has already had its pan and volume set, so the data matches the output.

It seems like the problem would have to be in this line of code:
double pan=cosine(rtheta)*-20.0; //?
But I see nothing that would explain the weirdness in that.
Questionmark?

CAE, the first thing that jumps out and concerns me is that your relative and absolute angles show up the same in every situation.

The first thing that popped out at me is this line of your code.
double xd=listener_position.x-sound_position.x;
I think you need to reverse the listener and sound_position.
double xd=sound_position.x-listener_position.x;

Leave the Y coordinate line as it is though.  The order is reversed for the Y coordinate line.  Since you're trying to have this handle a Z dimension as well, I have no idea how it should be handled.  For now I'd actually just leave it out because it is entirely possible that modifying my 2D code example to handle 3D might take a lot more changing to make the math work.  I would have to sit down and figure it out, but that's my recommendation for now.

double yd=listener_position.y-sound_position.y;

This line needs to be reversed as well.
if(xd>0) atheta=arc_tangent(yd/xd);
I think it should be arc_tangent(xd/yd) instead of yd/xd.

The same is true for the other line.
if(xd<0) atheta=arc_tangent(yd/xd)+PI;
Flip the yd and xd

This line is missing something I think.
atheta = (atheta * (180 / PI));
I believe it needs to have 90 subtracted from it in order to correctly orient the axis.
atheta = (atheta * (180 / PI))-90;

Here's another line that I think needs to be shifted.
double pan=cosine(rtheta*PI/180);
I also think it would need 90 subtracted from it.
double pan=cosine((rtheta-90)*PI/180);

Also this one.
double volume=sine(rtheta*PI/180);
I think would be
double volume=sine((rtheta-90)*PI/180);

I think that's it.  It's 5:11am and I haven't been to bed yet, so please be sure to make a backup copy of your current code before you go and make any of these adjustments, ROFL!  Especially since I'm tired, I wouldn't put a whole lot of faith in these. 

wow... just looked through this stuff and unfortunately, i don't get it... i understood the simplified explanation that ghorth gave earlier though.  If only making grids and such was simpler.  I tried doing that once in DFE and it didn't do what i was trying to make it do... its a shame really.

But at least aprone, you're doing amazing work in trying to tell people how you do things!  you're an inspiration!
The Doctor.
p.s. i might use your vb code from the other thread to work on a project i've had in the back of my mind for some time.  that is, if i can be bothered!

Is that vector projection?  For some reason I'm failing trig this morning.  It doesn't look like an actual rotation, however, unless there's a major simplification of the formula I have in mind in computer land: to rotate point p around point q, shift p by -q.x and -q.y, convert to polar, add to theta, and convert back.  Or use a transformation matrix, but that is probably more inefficient in this case.
Can you link the page you found this?  I want to see their explanation.  I thought I had enough math to derive any vector formula I needed-guess not.  My particular solution means I don't have to, however, but I'm still curious.

Yes, but I'm not sure what it's doing.  It's not rotation, it appears to be some sort of projection of a vector onto another vector, and I'd like to find out because that's just a bit weird.  I'm going to have to go review some trig now I think.
If I pass in the point (0,1) for p, the point (0,0) for O, and pi/2 for theta, do I get (1,0)?  Or is it doing something else?

Actually, some of that isn't really far beyond 8th grade if you take any honors math.  I had enough trig for this stuff by tenth grade.  My implementation is less efficient than yours, involving two square roots and 4 square operations.  Yours is multiplying by the 2d transformation matrix, but I can't find an explanation of why the 2d  transformation matrix works, only that it does.  Oddly, I have some stuff wherein I derived the 3d transformation matrix, so maybe I need to look at that.

edit: I derived the simple case of ignoring z and not wishing to do any rotations, only transformations, so it doesn't have the info I needed.
Also, the theta in your example is clockwise, I believe.  This isn't a big deal unless you know trig or beyond, in which all theta values are counterclockwise for everything.  The math convention is that theta of zero is to the right and that positive theta means counterclockwise-theta of pi/4 points upright, and 3pi/4 points up left instead of down right and down left respectively.  If anyone comes after me, thinks this is a cool function, and knows the basics of trig, beware of this.  I suspect that my example of (0,1) about (0,0) and theta of pi/2 will actually return (0,-1), but have not tried.

I know that.  Even so, if one is expecting the trigonometric theta, one is in for a surprise.  I understand the typical coordinate system (except, it's actually not so typical once you go into 3d graphics) for computers.  My personal preference--since Open AL lets you change the coordinate system easily--is to make the coordinate system match the standard trigonometric one.  For OpenGL, you basically specify your own, and if you get outside the trap of "because graphics says so"--we aren't rendering graphics in many cases--you can basically have whatever you want.  Changing that function to make theta go counterclockwise again is simply flipping a minus to a plus.
I still want to find out why the 2d transformation matrix works; everyone simply gives it as a given, and the explanations I can find involve complex numbers and Euler's identities and theorems.  Given that I can algebraically derive a less efficient approach (multiply the hypotenuse by the sine and cosine with the desired theta), I suspect there is a small step from what I have to what this function has.  I can't find it.  I do have to learn those things anyway, so i may just need to build up to it; one of my areas of interest involves the DFT and convolution, both of which use those concepts heavily anyway.

edit:
For those looking for the steps to get from general trig knowledge to these formulas, this thread:
http://www.gamedev.net/topic/286454-sim … -rotation/
Has it in a reasonably accessible form as post 2.  The last step that I didn't have was a very interesting algebra trick that I really should have seen coming and a couple of trig identities no one remembers off the top of their head (for some value of no one anyway).   You combine the formulas for converting to polar with the formula for a rotation in polar coordinates, expand with a trig identity, and do a clever substitution using an earlier step in the problem to get to the formulas in CAE_Jones's post.

Hello,
So taken my assumptions from the above post, I did:
#start code
import math
sqrt = math.sqrt

sound = (5,2)
player = (10,2)
theta = 270
mya, myb = player
sounda, soundb = sound

temp1 = sounda - mya
temp2 = myb - soundb
if temp1 == 0 and temp2 == 0:
    absolutetheta = -1
elif temp2 > 0:
    absolutetheta = math.atan(temp1/temp2)
elif temp2 <= 0:
    if temp2 == 0:
        absolutetheta = 3.14
    else:
        absolutetheta = math.atan(temp1/temp2) + 3.14
absolutetheta = (absolutetheta * (180 / 3.14))
relativetheta = absolutetheta - theta

print(relativetheta)
#end of code

There is something strange going on. If I change the sound coords to 15,2 the result that comes out is still -90 instead of 90.
I think the problem is with the temp1 and temp2 lines, but I am not going to pretend to understand what is going on mathematically to error-check the other lines. I put in a check in the last elif statement that defaults absolutetheta to 3.14 if temp2 is 0 as most calculators really don't like dividing anything by 0, but that is the only change I did to what Aprone wrote on the first post.
After this gets figured out, I went ahead and worked out the panning line:
h = math.cos(relativetheta * 3.14 / 180)

And it returns a positive number, even though the sound should be negative.
If anyone can let me know what is going on, I would love to know!
Thanks,

Hello,
I changed everything to floats and entered pi and I still get the wrong result.
I believe with the player at 10,2 and the sound at 5,2 the result should be -90, but with the sound at 15,2 the sound should be at 90?
What is a good transformation matrices library?
Because I would rather use something someone else made than create my own...

I didn't even see any good documentation on gameobjects, just the API...
I think I'm closer to figuring this out than gameobjects...
But I don't know what atan does, so don't know how to error-check it. I'm actually completely lost at what any of the math is doing... I can just tell we're working with circles and I want a 90 degree angle one positive and one negative I think...

Hello,
I'm using python2, but I converted all numbers to a floatingpoint.
Here is what aprone says about pa:
If relativetheta was equal to zero, then the sound is exactly in front of us.  If relativetheta equals 45 then the sound is 45 degrees to our right, putting it halfway between being in front of us and being exactly to our right.  180 would be behind us and 270 would be directly off to our left.
According to aprone's first post, 270 is facing north. His  equation:
elif temp2 <= 0:
        a = atan(temp1/temp2) + pi

doesn't work because you can't divide a number by 0.
It also doesn't take into account the temp1 variable if temp2 is 0.
Then what is happening is you have a equal to pi and then you multiply 180/pi by a and it comes back to 180. Then you subtract 270 (pa) from 180.
a = (a * (180.0 / pi))
pa = float(a - pa)

from math import pi, sqrt, cos, atan

sound = (5.0,2.0)
player = (10.0,2.0)
pa = 270.0

temp1 = float(sound[0] - player[0])
temp2 = float(player[1] - sound[1])
if temp1 == 0 and temp2 == 0:
    a = -1.0
elif temp2 > 0:
    a = atan(temp1/temp2)
elif temp2 <= 0:
    if temp2 == 0:
        a = pi
    else:
        a = atan(temp1/temp2) + pi
a = (a * (180.0 / pi))
pa = float(a - pa)

print(pa)

*edit*
Looking at Aprone's post 31, he says something completely different.
He says it should look like:

if temp1 == 0 and temp2 == 0:
    a = -1.0
elif temp1 > 0:
    a = atan(temp1/temp2)
elif temp1 <= 0:
    if temp2 == 0:
        a = pi
    else:
        a = atan(temp1/temp2) + pi
a = (a * (180.0 / pi))-90

Aprone really likes dividing his numbers by 0 doesn't he
This doesn't give the right numbers either. It just changes the -90 to +90...