Hi,
Yes I understand that, What I don't understand is:
Say, a grid is 10 by 10 squares big, (x 10, y 10), so it's a 2D grid. Now, instead of saying:
for a in range(1,10,1):
sound.position=(a,0,0)
Why is that x number so high, (200). And what does incrementing by 64 mean?

Are we talking about the 3D audio example? The numbers for that are largely arbitrary, but served the particular purpose of demonstrating the panning effect. With the rolloff factor set low the distances needed to be larger to get the same panning effect, I'd set the Y position of the listener and the player at 240, no particular reason really. The listener's X position was set to 320, and the players X position to 0. Now this puts the player squarely on the left side of the listener, and in order for it to move over to the same position on the right side of the listener it needs to move to 640. I didn't want it to play constantly along the way so made it so it would play at 64 step intervals to play 10 times, plus another 64 for a total position of 704 because the player would also be in front of the listener at one point, which thinking about it might not be quite right, but eh.

Bottom line being, don't worry too much about the specifics of that particular example, its arbitrary and doesn't really matter.

-BrushTone v1.3.3: Accessible Paint Tool
-AudiMesh3D v1.0.0: Accessible 3D Model Viewer

So reviving this old topic, yea!
I'm trying to find a sweet balance between the volume and the sound fading away. I have tried the rolloffs between 0.1 and 40, and I still can hear the sounds when they're like... 100 units away. Suggestions?
Also, the volume drastically jumps between the listener and the player when the player is 1-2 units away when I raise the factor higher, ideas on how to soften that?

Coding is not hard. No, not at all.
What is hard is making code that accepts different and sometimes unexpected types of input and still works.
This is what truly takes a large amount of effort on a developer's part.

With the roll off factor, the higher the value, the steeper the volume drop over a shorter distance. The lower the value, the more gradual, and longer the distance from the listener. You could try adjusting the sounds volume, but there are also other factors involved with the roll off distance models not currently implemented in the player handler class, though the bindings are in place. For example:

``````// The distance that the source will be the loudest (if the listener is
// closer, it won't be any louder than if they were at this distance)
alSourcei(source, AL_REFERENCE_DISTANCE, 1.0);
// The distance that the source will be the quietest (if the listener is
// farther, it won't be any quieter than if they were at this distance)
alSourcei(source, AL_MAX_DISTANCE, FLT_MAX);``````

There are also settings for different distance models, such as AL_INVERSE_DISTANCE, AL_INVERSE_DISTANCE_CLAMPED, AL_LINEAR_DISTANCE, AL_LINEAR_DISTANCE_CLAMPED, AL_EXPONENT_DISTANCE, AL_EXPONENT_DISTANCE_CLAMPED, or AL_NONE. For the AL_INVERSE_DISTANCE model the formula works like this:

``gain = AL_REFERENCE_DISTANCE / (AL_REFERENCE_DISTANCE + AL_ROLLOFF_FACTOR * (distance – AL_REFERENCE_DISTANCE))``

These settings help adjust the effects of volume distance attenuation and drop off. If you like I can try adding them in and you can playing around with them. Or also you could also checkout the [Openal Programmers Guide], which covers some of the nitty gritty of source functions and calls.

-BrushTone v1.3.3: Accessible Paint Tool
-AudiMesh3D v1.0.0: Accessible 3D Model Viewer

Sorry for a late reply, I would appreciate if you add the things you listed above.  Like I said, the major issue for me right now is volume.

Coding is not hard. No, not at all.
What is hard is making code that accepts different and sometimes unexpected types of input and still works.
This is what truly takes a large amount of effort on a developer's part.