OpenSource Object Pascal Module Playback Library

[WILL]

openal is like opengl it the way that harware providers come with a openal.dll file optimized for their hardware. It is like a driver. OpenAL is availeble for windows,linux and mac. So we have to keep up with an dll for that. But that is not bad i think as we automaticaly gain support for the latest hardware always.

Mixing can be done in hardware or software. Or to say it differently via:
directx
openal
sdl-mixer
asm
It makes things harder to support all as there are some different ways to gain the same result.
I used openal to get hardware accelerated (3d) mixing and to show off what openal is capable of. But using (virtual) classes it should be possible to combine all of them.
We could (sort of) emulate the openal api for asm and/or sdl.
OpenAL consistr of souces and buffers. A buffer holds the sound data and the source plays a buffer. This can be done in asm and sdl also.

Hmm... well I can see the benifit of the 3D mixing, but then again... what aspecs of 3D sound give where the module format does not support it? We could make seperate versions that use OpenAL, DirectX, etc, but we'd still want to have a generic plain-jane mixer that can be implemented into, well... anything!

We are not trying to prove or show off anything here with this project. We just want to make an amazing MOD playback engine(meaning mixer, not sound playback). For the demos, that is a very different case. We will require using other playback libs for them. But for this project, we are not trying to make an add-on to any lib at all. We are trying to make a standalone lib for mod mixing/streaming. The MAIN featured release should be our lib(s) ONLY. ie. No DirectX and no OpenAL, no SDL, etc.

Demos for our lib(s) will be a very different case we can use SDL & OpenAL and another demo using DelphiX & DirectSound, etc... We can use them all there. But the core project is specifically the MOD lib(s). I hope I clairified what the focus on the project idea is.

Hmm... perhaps I can lend a hand there. in-line ASM shouldn't be too different from C to Pascal, since it's the exact same language, just at worst case different conventions. ie. 0xFF0F instead of $FF0F. Too easy, right? When I have a bot more time I'll have a look too.

True but my main concern here is the difference between MASM and BASM. Delphi uses the BASM dialect and the miniFMOD code uses V C++, wich I assume uses the MASM dialect. Where most of the instructions may be similar my concern is some may be different.

Not a problem. They can't be different. It's machine level at is lowest possible form. AND this is published hardware commands nothing to do with software, except the IDE. When you type a command you do so by it's actual published Intel name. It's standardized this way.

Well, I would like to allow anyone to use this library to be used in commercial projects without having to pay a licence. But it would be nice to have a mention in the credits or whatever they have for the music engine.

-k- I'll look into some other licences and see what works best. :-)

Hmm... ok. If one does not exist, can we make our own? Or will SourceForge get all pissy?

Ok, one point with this. OpenAL is a library for Sound output and should not be apart of the project. We are not just creating a MOD Player, we are creating a MOD Library/Mixer, right? The only thing that would be using OpenAL for(and with perfect sense) is to make the demo player that would use OpenAL as it's sound playback for the mixed output from OUR openMOD library. the reason I am saying this is because we should allow any sound engine to playback audio renered from our mixer. This will keep the project open-ended and more compatable with more and more platforms, ie. Windows, Linux, MacOS(capable, but with little support) using OpenAL, DirectSound, etc... Also it will allow for people to make an MOD2MP3, etc type processing programs, etc... And our project will be more widely excepted because of it's multi-use.

I see your point. Then what we need to do is at some point define a sound engine interface that will allow people to write "drivers" per say. In that interface can be a flag that will allow for internal mixing or Driver mixing depending on what works best for the particular driver implimentation.

Hmm... well this is intirely possible. But might end up being costly if some programers do not want to use a particular lib for playback. ie. Wants to use DelphiX with DirectX instead of SDL with OpenAL. We'd be best to seperate "Driver" specific functionality into other units and release SDL only, DelphiX only, core only and complete packages if we wish to do that. Then again, we'd be best to work on the CORE MOD lib then go ahead with the variations. Then again we'd want to have a "common" playback program made up to interface with it. And that of course would require the use of a sound driver set.

As a side note; I'd recommend SDL w/ OpenAL since I will be moving to Linux over the new year and it would seriously effect my ability to help development until we had something ready for me to compile/run. :? Sorry if this makes a problem, guys. On a positive note, I'm going to be a deticated Kylix contributor/developer.

Well, any ASM in my oppinion should be encompased in a function or procedure where it can be used as such by everyone should the need arise for it's use AND be well commented and state exactly what it does and for what conditions.

Ok I can see that but it will also need compiler conditionals to make sure that the right thing is compiled for the right platform. I think that also we should try to have an alternate pascal implimentation of the same functions so that we still don't loose portibility.

We could do it without compiler conditionals(I try to do these kinds of things in code first usually). If we can auto detect the CPU(not too hard) then we can tell if a CPU will support a specific CPU instruction or not. And with this we take it to a boarder issue of using a different Pascal function that encompasses the CPU specific functions. we'll have out main render/update/stream(whatever we call it) function read the flags that tell us the conditions and runs the proper functions to render the next stream of audio. And where we cannot detect conditions(ie. need DirectX or OpenAL to do these type of detections) we simply add a parameter in the init function that toggles this OR we set the feature/enhancement to OFF by default and let the programer decide how he want to determine if it's there or not and they turn it on via a enh_EAX(True); function. Or something to this general effect.

I just checked this morning and SF has not got back to me yet. :-?
I'll keep yall posted... :-)

-Jeremy

Poop. Email them and bug them.

I've got a program called WinCVS 1.2(it has a 'gCVS' counterpart). I'll be moved to Linux after Jan 9th, 2004 so by then I'll have to figure out the gCVS instead. I hopt to try it in Windows first. :?