OpenAL Bindings Question

[ShadowLordAlpha]

When using the other libraries that LWJGL 3 provides LWJGL acts as a very thin wrapper that just brings the library into Java with some basic changes and extra methods along with some utility type classes that make it easier to use. However with OpenAL instead of simply wrapping the library like it does with the others it requires us to go though ALContext in order to use most of that library. Is there a reason why this is the case in this library and not with the others? Its perfectly fine I'm just curious as to why this is the only library that has this, from what I have messed around with.

[Spasi]

OpenCL also has similar classes (CLPlatform and CLDevice). Like ALDevice and ALContext, they don't do much and technically you could use the bindings without them. They serve two purposes:

• They create and store the capabilities classes internally.
• Getting started is easier. The user does not need to be exposed to the capability classes immediately, they only have to deal with the concepts of platform/device/context from the corresponding libraries. The capability classes are LWJGL-specific.

You've got a point though. I think I'll make another pass on CL and AL and maybe simplify things a bit before the 3.0.0 release. A problem with AL in particular is that the methods AL.setCurrentProcess and AL.setCurrentThread work with ALContext instances. That's an unnecessary dependency and they should work with ALCapabilities instead (and possibly remove ALContext and ALDevice entirely).

[ShadowLordAlpha]

My main thing was that its not really possible to use OpenAL without going through the ALContext class so we can't make code that looks basically the same as it would if we were programming it in C.

Another pass over those two libraries is probably a good idea and maybe some way around those classes so they are there if people want to use them but not needed. That way getting started is still easy but going that way is not required. Though to me it seems like returning the pointer and using that makes more sense here simply because that's how it seems to be done in the other common libraries (GLFWwindow for example)

[Spasi]

Opening the default device and creating a default context with the above changes and no error checks:

// Can call "alc" functions at any time
long device = alcOpenDevice((ByteBuffer)null);
ALCCapabilities deviceCaps = ALC.createCapabilities(device);

long context = alcCreateContext(device, (ByteBuffer)null);
alcMakeContextCurrent(context);
AL.createCapabilities(deviceCaps);
// Can now call "al" functions