OpenSource Object Pascal Module Playback Library

[WILL]

Hey guys. So much to respond to. Thats a really good thing though.

I will set up the sf project today under the possible names of openmod, or crossmod.... dunno yet but I will get that ball rolling. After the project is set up I'll have you send me the tech files through that.

I have got the registration process complete. Now just waiting on sf to notify me that they have set up the project.

Excellent! The "OpenMOD Project" might be a good name. I'll gather all of my technical files on mods and mod formats. Basically what I have is the specs that were given from the creators of the trackers themselves, plus some other docs on other things.

Sorry about the depressing tone of my last post. I had just got off the phone with my head hunter and it sounds like I'm not going to see anything till after the new year. I've been out sense oct 30th. Anyways enough of my problems... I'll posty back here when I have the project up.

Not a problem. We all have rough times here and there. I hope you will find some work in the new year.

please do not use asm, only pure object pascal code please! That way we keep the project open for compiling on mac os. (yes there is an object pascal compiler for mac-osx!)
Mixing is done using openal. (multiple source). Also no mixing should be done by software. OpenAL wil use hardware-mixing when available.
It makes things harder to program, but the end result will be better, both in speed and portability.

Well there is indeed a work-around, I believe, for this issue as to my understanding we can use ifdefs and other code to determine what chip is in use. ie. X86 or Pentium it'll use a speedier Intel/AMD optimized set of functions, etc However if the MacOS's Pascal compiler doesn't support in-line ASM then we are out of luck. But if OpenAL can take advantage of multi-channel audio mixing using hardware optimization then we should be in the green. Though we could always branch off and have some sort of way to switch on/off the X86(in-line ASM) support.

I do have some experience with ASM along with some digital electronics experience(if that counts for anything here ), but I may be a bit rusty. We'll see if it's a usefull skill.

What file formats are we all interested in?

Definately MOD(all common types), S3M(Scream Tracker 3), XM(Fast Tracker) and IT(Impulse Tracker, the best MOD format to date). Of course we can add others, but these are the basics, I think.


CVS; I'll have to look into this a bit. I have never used one of these systems and have not a clue how it works. If you could give me a small primer, I'd be truely greatful. Any software that would help in the process(Win32/Linux cross-platform would be best since I'm moving to Linux in Jan 2004) that you could recommend, that'd help too.

[WILL]

I just foud this link here. And it seems to have all of the files that we would need to start and then some.

As for my old code, I'd have to rummage through my old source CD backups back home. Mind you, I don't think it would be of huge use since I could probably recreate the same effect of the code in a much shorter time and in a more up-to-date fashion(heck it was TP7 code man!).

I think in the meantime, I'll just work on some basic S3M, XM and IT loaders.

[Sly]

If you wanted to look at some C code that was solely dedicated to the fast and efficient playback of MOD and MOD-based files, take a look at minifmod at http://www.fmod.org. I started converting it to Delphi ages back, but got stuck at the inline ASM. Unfortunately I no longer have the code that I had converted with me.

[wilbur989]

I also have looked at the mini fmod code and basicly could only stare at the asm. What I did figure out is that most of it is used to mix the sample streams into a stereo stream and send it out tho the playback device. i.e sound card.

WILL

CVS; I'll have to look into this a bit. I have never used one of these systems and have not a clue how it works. If you could give me a small primer, I'd be truely greatful. Any software that would help in the process(Win32/Linux cross-platform would be best since I'm moving to Linux in Jan 2004) that you could recommend, that'd help too.

For cvs command line primer try this link. http://www.cvshome.org/docs/manual/c...vs_1.html#SEC1
For some possible tools to use cvs in a gui environment try http://www.loria.fr/cgi-bin/molli/wilma.cgi/rel
other then that sf has a little cvs help that is linked int all of ther project pages, so those are going to be the best bet.

I agree with noeska, we should try to avoid hand optimized asm as much as possible, and yes if we do have to use asm ifdefs they are an option in both compilers. As far as I am aware ther are two cross compilers out there that have os X support, one is free pascal the other is gnu pascal. I'm not sure which noeska was refering but I like the idea of using Free pascal for cross platform work. But the inital development will still need to be delphi/kylix as that is where most of my experiance is right now.

-jeremy

[noeska]

what license will be used? If placed under opensource will it effect commercial usage? MPL license? My mod player was/is intended to be included in 3D Adventure Studio.

I only know of the gnu pascal osx compiler. If there is a free pascal version available that is better. I do not like the gnu license.

Also when will the sf site be available. I beleive an account is already created?

[wilbur989]

I listed it as the BSD licence, sense it is the least restrictive, but nothing is set in stone yet. As to the sf project, I went through the setup process yeasterday and am waiting to hear back from them.

Free Pascal will have a mac compiler, it is not complete yet, and apparently it only targets the powerPC chipset. Sense I don't know much about macs I have no idea weather this is good or bad.

I was not going to use anyones code till I knew that everyone involved agreed to the license and where the project is heading. But from what I've heard thus far using OpenAL as the sound engine makes the most sense. I just wish it could be staticlly linked into the binary rather then using a .dll or .so ah well we will see as we go I geuss :-)

-Jeremy

[WILL]

For cvs command line primer try this ]http://www.cvshome.org/docs/manual/cvs-1.11.10/cvs_1.html#SEC1[/url]
For some possible tools to use cvs in a gui environment try http://www.loria.fr/cgi-bin/molli/wilma.cgi/rel
other then that sf has a little cvs help that is linked int all of ther project pages, so those are going to be the best bet.

Thanks, this does help quite a bit.

I also have looked at the mini fmod code and basicly could only stare at the asm. What I did figure out is that most of it is used to mix the sample streams into a stereo stream and send it out tho the playback device. i.e sound card.

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.

I listed it as the BSD licence, sense it is the least restrictive, but nothing is set in stone yet. As to the sf project, I went through the setup process yeasterday and am waiting to hear back from them.

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.

Free Pascal will have a mac compiler, it is not complete yet, and apparently it only targets the powerPC chipset. Sense I don't know much about macs I have no idea weather this is good or bad.

I'd say that it's not too good. We can only support platforms up to the point that have supported compilers for that OS/system. It seems like we basically have Windows & Linux OSes and X86 & AMD Chips with proper support for both. MacOS/PowerPC, G4, etc, seem to be a bit of a streach for us, but we should leave an open end for it so that others that have Mac expertise(and should Borland move that way too)may contribute later on.

[quote="wilbur989"]I was not going to use anyones code till I knew that everyone involved agreed to the license and where the project is heading. But from what I've heard thus far using OpenAL as the sound engine makes the most sense. I just wish it could be staticlly ]

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 agree with noeska, we should try to avoid hand optimized asm as much as possible, and yes if we do have to use asm ifdefs they are an option in both compilers. As far as I am aware ther are two cross compilers out there that have os X support, one is free pascal the other is gnu pascal. I'm not sure which noeska was refering but I like the idea of using Free pascal for cross platform work. But the inital development will still need to be delphi/kylix as that is where most of my experiance is right now.

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.

ie.[pascal]{mixes number of channels for X86 Family with MMX}
function mix_X86_MMX(var chncnt:Integer): PChar; Assembler;
asm
...
end;
{mixes number of channels for AMD Family with MMX}
function mix_AMD_MMX(var chncnt:Integer): PChar; Assembler;
asm
...
end;
{mixes number of channels for AMD Family with 3DNow!}
function mix_AMD_3DNOW(var chncnt:Integer): PChar; Assembler;
asm
...
end;[/pascal][size=9px](oh and btw, the newer AMDs do support MMX, neat huh? )[/size]

And so on. If we know what is allowed and what is not for each system(we can incorporate all this into the init function of course) and provide the proper functions and methods to detect what we need to detect, we will have a moer powerful MOD mixer.

[noeska]

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.

[wilbur989]

Thanks, this does help quite a bit.

No Prolem :-)

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.

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. :-)

I'd say that it's not too good. We can only support platforms up to the point that have supported compilers for that OS/system. It seems like we basically have Windows & Linux OSes and X86 & AMD Chips with proper support for both. MacOS/PowerPC, G4, etc, seem to be a bit of a streach for us, but we should leave an open end for it so that others that have Mac expertise(and should Borland move that way too)may contribute later on.

I agree there.

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.

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.

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.

Right the only thing that we are also trying to acomplish is that if someone has no desire to be dependant on OpenAL then they have a choice with some other sound deveice driver(sort of :-)). With a device interface tok the component all someone has to do is choose which sound system they want to use and go with it.

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

-Jeremy

[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. :?