PDA

View Full Version : OpenSource Object Pascal Module Playback Library



WILL
17-12-2003, 12:25 AM
Hmm... this isn't a project that has begun yet, but what better place to see if there is an interest in this.

Please read the following threads 1 (http://terraqueous.f2o.org/dgdev/viewtopic.php?t=1065) & 2 (http://terraqueous.f2o.org/dgdev/viewtopic.php?t=1066) and tell me what you think of my project idea.

The idea is to take existing code from this small project on sourceforge using existing tech data and C code and create an open source Object Pascal version of a play back library that loads, detects and mixes MODs, S3Ms, XMs and ITs plus whatever else the team can think of.

The reasons are simple:

1) There fails to exist a FREE for EVERYTHING, cross-platform, mixer/playback library that can play a vast majority of module formats and produces high quality mixing output.

2) There is not an Object Pascal, open source module library that can play a vast majority of module formats and produces high quality mixing output.

3) Modules are an extreemly amazing way to include music into your games and they keep the file sizes down without having to resort to the use of heafty MP3 encoded WAV files.


Would anyone be interested in this type of project? Myself and one other would definately be a contributor to it.

Harry Hunt
17-12-2003, 06:10 AM
Sounds like a fantastic project. I don't have time to help you because I'm working on the new xcess gdk at the moment but I would be very interested in something like that.

WILL
17-12-2003, 10:58 AM
Well it would indeed be on par with the C code-based projects of back in the days, but only we'd be doing it in Object Pascal(Delphi & Kylix).

wilbur989
17-12-2003, 04:33 PM
I've got nothing but time... Unemployed at the moment :-(. What would you like me to do?

-Jeremy

WILL
18-12-2003, 01:18 AM
Well from what we seem to be heading for we would take a look at what noeska has done with his small mod player then see if we can expand on it.

I have a ton of tech files and some source code of my own. I am willing to contribute these and some extra time to work on aspects of a MOD mixer/player that will eventually include S3M, XM and IT module formats. But, only if others will contribute aswell.

As for what you could do? Well, what can you do? In-line ASM, Audio algos, knowlage of MOD type formats, etc would be useful. I'm thinking that we should not worry about the actual playback of the audio(why re-invent the wheel?) rather we concentrate on the mixing of the audio. ie. Making a streamed output of raw audio that can be fed to a playback device or engine. This will make the project 100% cross-compatable. I don't know the best format for Kylix libraries(equivilent of Dynamic Link Library files), but if we make it a simple unit to start we should be ok.

Here's a question; Would you be willing to manage a sourceforge site for this project?

wilbur989
18-12-2003, 03:02 PM
Here's a question; Would you be willing to manage a sourceforge site for this project?

NO problem....


As for what you could do? Well, what can you do? In-line ASM, Audio algos, knowlage of MOD type formats, etc would be useful. I'm thinking that we should not worry about the actual playback of the audio(why re-invent the wheel?) rather we concentrate on the mixing of the audio. ie. Making a streamed output of raw audio that can be fed to a playback device or engine. This will make the project 100% cross-compatable. I don't know the best format for Kylix libraries(equivilent of Dynamic Link Library files), but if we make it a simple unit to start we should be ok.

I have enough experiance to handle most of this I am shakey with asm though. I guess it's time to learn huh? :-)
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.

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.

-Jeremy

wilbur989
18-12-2003, 03:41 PM
I have got the registration process complete. Now just waiting on sf to notify me that they have set up the project.

-Jeremy

noeska
18-12-2003, 05:32 PM
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.

Mrwb
18-12-2003, 05:45 PM
I would be really interested in contributing, but my programming skills are somewhat limited, I'm still in the learning process ;)

So if there is anything I can do wich doesen't require really advanced programming, please let me know. :)

wilbur989
19-12-2003, 01:22 AM
Mrwb

I would be really interested in contributing, but my programming skills are somewhat limited, I'm still in the learning process

So if there is anything I can do wich doesen't require really advanced programming, please let me know.

No problem here... I do suggest you look into cvs stuff as that is the only way that you can get and send data to the project.

noeska

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.

That was the origal plan anyway. I was only saying that in case it did become an issue later.

I was also planning on writing it so that it will compile in not only delphi/kylix but it will also compile in Free Pascal. I'm playing with 1.9 for right now.

I grabbed your player code and will look at it in the morning to get an idea as to where to go from here.

What file formats are we all interested in?

-Jeremy

WILL
19-12-2003, 01:59 AM
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
19-12-2003, 03:43 AM
I just foud this link here (http://jss.sourceforge.net/moddoc/). 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
19-12-2003, 01:15 PM
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
19-12-2003, 02:47 PM
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/cvs-1.11.10/cvs_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
19-12-2003, 05:29 PM
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
19-12-2003, 10:20 PM
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
20-12-2003, 02:58 AM
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.


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.

[quote="wilbur989"]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.{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;(oh and btw, the newer AMDs do support MMX, neat huh? :))

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
20-12-2003, 09:02 AM
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
20-12-2003, 03:13 PM
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
21-12-2003, 03:52 AM
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. :D



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

noeska
21-12-2003, 10:22 AM
What we want from our license seems to be all in MPL.

Try reading the annotated version of it:
http://www.mozilla.org/MPL/MPL-1.0-annotated-fs.html

For using the mod library (code) in your own (commercial) program the annotation says:
``Distribution of Executable Versions''
The goal of the NPL and the MozPL is to encourage as much innovation as possible. We anticipate that people will take the code licensed under the NPL and MozPL and combine it with code developed or licensed under other terms. We also anticipate that the combined code will be licensed under a variety of terms, including different payment terms, support terms and use restrictions. Netscape does not wish to dictate the terms under which any such executables will be available. The NPL and MozPL are designed to make sure that the Source Code Modifications are freely available. After that, the creator of a larger work is free to license the executable of the work as he or she sees fit.

See the last sentence.
But if you change something to the mod player you have to make it public. If you just use it as a part of another program it seems to be ok.

Also in the beginning mpl states:
The Initial Developer hereby grants You a world-wide, royalty-free, non-exclusive license, subject to third party intellectual property claims:
Look at the word royalty-free.

So it would be no problem to get the project at sf under mpl1.0 license.

WILL
21-12-2003, 08:59 PM
I must be honest and tell you that I'm far from a wiz at these licences, but from what I see it look pretty muct like what we would want.

So the gist of all this is;

:arrow: If they make modifications to our code and use that code they must state so in their project somewhere.
:arrow: They can use whatever binaries they make using our code under any licence they choose.

:?: If they use our source or binaries(we do plan on making binary version of our libraries right?) in their project they have to give us credit???

Is this right? What other "rules" or terms can we tack onto it to make sure that we get what we want out of the MPL?

noeska
22-12-2003, 05:46 PM
in short (as i read it):

-anyone can use our mod player source in their (commercial) project if given proper credit. (also a link to the mod player source?)
-if they change the source of the mod player the have to give us the changes they made to it.

Read the mpl license for full details. As the above is very short.

wilbur989
23-12-2003, 02:55 PM
[quote="noeska"]in short (as i read it):

-anyone can use our mod player source in their (commercial) project if given proper credit. (also a ]

That is how I understand it also.

I have started some of the component structure and as soon as SF gets the page set up I'll get it put up there. Still have yet to hear from them... Guess I better go harass them and find out what the hold up is.... :?

Anyways....

wilbur989
23-12-2003, 03:07 PM
I just found out there was a problem with the registration process I'm looking into it now and will let yall know what is wrong when I get some info from them.

-Jeremy

WILL
23-12-2003, 07:32 PM
[quote="noeska"]in short (as i read it):

-anyone can use our mod player source in their (commercial) project if given proper credit. (also a ]

Looks good to me.


Ok, well I've started to work on some loader code. You know, load_S3M, load_XM, load_IT functions. No point in making a load_MOD one since we can default to noeska's. Basically they load the whole header into a global variable of it's header type. That part is done along with a single simple validation function. As for loading patterns, orders, samples and instruments. I have yet to figure out the exact structure to use there. Samples should be rather easy though. The functions can moved into a TmodIT object for loading the header into it's self, etc.

Here is a clip of my code so you guys can see what track I'm on. I can move this code into what ever template wilbur989 sets so that we stay on track with a single set of source code.

type
MOD_Header = Record
SongName : Array[1..20] of Char;
Tag : Array[1..4] of Char;
Channels : Integer;
end;
S3M_Header = Record
SongName : Array[1..28] of Char;
Unknown1 : Byte;{should be '1A' in hex}
Typ : Byte;{File type: 16=module,17=song}
Unknown2 : Word;{Unknown!}
OrdNum : Word;{Number of orders in file}
InsNum : Word;{Number of instruments in file}
PatNum : Word;{Number of patterns in file}
Flags : Word;
TrackerVersion : Word;{Created with tracker / version}
FileFormatVersion : Word;
SCRM : Array[1..4] of Char;
MasterVolume : Byte;{master volume}
MasterMultiplier : Byte;{master multiplier (&15) + stereo(=+16)}
InitialSpeed : Byte;{initial speed (command A)}
InitialTemp : Byte;{initial tempo (command T)}
Unknown3 : Array[1..12] of Byte;
ChannelSettings : Array[1..32] of Byte;
end;
XM_Header = Record
IDText : Array[1..17] of Char;
SongName : Array[1..20] of Char;
Unknown1 : Byte;{should be '1A' in hex}
TrackerName : Array[1..20] of Char;
VersionMajor : Byte;{hi-byte major and low-byte minor}
VersionMinor : Byte;
end;
IT_Header = Record
IMPM : Array[1..4] of Char;
SongName : Array[1..26] of Char;
PatternHilight : Word;{Useless for playback}
OrderNumber : Word;
InstrumentNumber : Word;
SampleNumumber : Word;
PatternNumber : Word;
CreatedWith : Word;
CompatableWith : Word;
Flags : Word;
Special : Word;
GlobalVolume : Byte;
MixingVolume : Byte;
InitialSpeed : Byte;
InitialTempo : Byte;
PanningSeparation : Byte;
PitchWheelDepth : Byte;
MessageLength : Word;
MessageOffset : DWord;
end;

const
mtNon = 0;
mtMOD = 1;
mtS3M = 2;
mtXM = 3;
mtIT = 4;
mtOther = 5;


var
{Module Header Info}
ModuleType : Integer;
MODTag : MOD_Header;
S3MTag : S3M_Header;
XMTag : XM_Header;
ITTag : IT_Header;

implementation


function GetMODType(MODName: String): Integer;
var MODStr : Array[1 .. 4] of Char;
S3MType : S3M_Header;
XMStr : Array[1 .. 17] of Char;
ITStr : Array[1 .. 4] of Char;
FileStream: File;
begin
if (not FileExist(MODName)) then
begin
Result := -1;
Exit;
end;

AssignFile(FileStream, MODName);
Reset(FileStream, 1);

Seek(FileStream, 1080);
BlockRead(FileStream, MODStr, SizeOf(MODStr));

Seek(FileStream, 0);
BlockRead(FileStream, S3MType, SizeOf(S3MType));

Seek(FileStream, 0);
BlockRead(FileStream, XMStr, SizeOf(XMStr));

Seek(FileStream, 0);
BlockRead(FileStream, ITStr, SizeOf(ITStr));

CloseFile(FileStream);

Result := mtOther;
if (MODStr = 'M.K.') or (MODStr = '6CHN') or (MODStr = '8CHN') then
Result := mtMOD;
if (S3MType.SCRM = 'SCRM') then
Result := mtS3M;
if (XMStr = 'Extended Module: ') then
Result := mtXM;
if (ITStr = 'IMPM') then
Result := mtIT;
end;

procedure Load_MODHeader;
var FileStream : File;
begin
{Read Header From File}
AssignFile(FileStream, SongFileName);
Reset(FileStream, 1);

BlockRead(FileStream, MODTag.SongName, SizeOf(MODTag.SongName));
Seek(FileStream, 1080);
BlockRead(FileStream, MODTag.Tag, SizeOf(MODTag.Tag));

CloseFile(FileStream);

{Display MOD Information}
if (MODTag.Tag = 'M.K.') or
(MODTag.Tag = '6CHN') or
(MODTag.Tag = '8CHN') then
begin
{Display SongName}
Main.SongTitle.Caption := MakeStr(MODTag.SongName);
end;
end;
procedure Load_S3MHeader;
var FileStreem : File;
begin
{Read Header From File}
AssignFile(FileStreem, SongFileName);
Reset(FileStreem, 1);

BlockRead(FileStreem, S3MTag, SizeOf(S3MTag));

CloseFile(FileStreem);

{Display S3M Information}
if (S3MTag.SCRM = 'SCRM') then
begin
{Display SongName}
Main.SongTitle.Caption := MakeStr(S3MTag.SongName);
end;
end;
procedure Load_XMHeader;
var FileStreem : File;
begin
{Read Header From File}
AssignFile(FileStreem, SongFileName);
Reset(FileStreem, 1);

BlockRead(FileStreem, XMTag, SizeOf(XMTag));

CloseFile(FileStreem);

{Display S3M Information}
if (XMTag.IDText = 'Extended Module: ') then
begin
{Display SongName}
Main.SongTitle.Caption := MakeStr(XMTag.SongName);
end;
end;
procedure Load_ITHeader;
var FileStreem : File;
begin
{Read Header From File}
AssignFile(FileStreem, SongFileName);
Reset(FileStreem, 1);

BlockRead(FileStreem, ITTag, SizeOf(ITTag));

CloseFile(FileStreem);

{Display S3M Information}
if (ITTag.IMPM = 'IMPM') then
begin
{Display SongName}
Main.SongTitle.Caption := MakeStr(ITTag.SongName);
end;
end;


Actually I lied. I did make a Load_MODHeader function, but it's only a part of my old code for my multi-format music player from a year or two ago. And it's not a very good one at that. :? It'll be replaced I'm sure. ;)

It's coming close to the date of my flight, I mgiht just send the code by email if the sourceforge isn't up soon.

wilbur989
23-12-2003, 11:47 PM
I did make a Load_MODHeader function, but it's only a part of my old code for my multi-format music player from a year or two ago. And it's not a very good one at that. It'll be replaced I'm sure.

It's coming close to the date of my flight, I mgiht just send the code by email if the sourceforge isn't up soon.

Kool Looking good Now I'll Show you the component code that I have started thus far. Remember this is just the mod format so Chances are this is really subject to change. There is aslo alot of debug properties that will not be neede in the final version so if you see somthing either redundant or wierd that is probably why. Also I'm to the point of loading the sample data so it will probably have more code to it By the time SF has the project fixed. BTW at this point I dont expect to see that done till after Christmas. :-?

-Jeremy

unit OpenModPlayer;

interface

uses
SysUtils, Classes;

type
TSampHeader = Record
Name: String[22];
Length: Word;
FineTune: ShortInt;
Volume: Byte;
LoopStart: Word;
LoopLength: Word;
End;

TModHeader = Record
Name: String[20];
Verified: Boolean;
Channels: ShortInt;
SongLength: Byte;
TotalPatterns: Byte;
Order: Array [1..128] of Byte;
SampleHead: Array [1..31] of TSampHeader;
end;

TOpenModPlayer = class(TComponent)
private
FDataStream: TFileStream;
FHeader: TModHeader;
FOpened: Boolean;
// FVerified: Boolean;
// FChannels: Integer;
// FModName: String;
procedure SetOpened(const Value: Boolean);
procedure SetVerified(const Value: Boolean);
Function Verify: String;
procedure SetChannels(const Value: Integer);
procedure SetModName(const Value: String);
procedure Load;
function GetChannels: Integer;
function GetModName: String;
function GetVerified: Boolean;
function GetSample(Index: Integer): TSampHeader;
procedure SetSample(Index: Integer; const Value: TSampHeader);
protected
{ Protected declarations }
public
procedure Open(FileName: String);
Property ModName: String read GetModName write SetModName;
Property Channels: Integer read GetChannels write SetChannels;
Property Verified: Boolean read GetVerified write SetVerified;
Property Sample[Index:Integer]: TSampHeader read GetSample write SetSample;
Property Opened: Boolean read FOpened write SetOpened;
Property Header: TModHeader read FHeader;
{ Published declarations }
end;

procedure Register;

implementation

procedure Register;
begin
RegisterComponents('OpenMod', [TOpenModPlayer]);
end;

{ TOpenModPlayer }

function TOpenModPlayer.GetChannels: Integer;
begin
Result := FHeader.Channels;
end;

function TOpenModPlayer.GetModName: String;
begin
Result := FHeader.Name;
end;

function TOpenModPlayer.GetSample(Index: Integer): TSampHeader;
begin
Result := FHeader.SampleHead[Index];
end;

function TOpenModPlayer.GetVerified: Boolean;
begin
Result := FHeader.Verified;
end;

procedure TOpenModPlayer.Load;
var
I: Integer;
TmpByte1, tmpByte2: Byte;

begin
//Load Modual Values
FDataStream.Seek(0,0);
FHeader.Name := StringOfChar(' ', 20);
FDataStream.Read(FHeader.Name[1], 20);
For I := 1 to 31 do
begin
FHeader.SampleHead[I].Name := StringOfChar(' ', 22);
FDataStream.Read(FHeader.SampleHead[I].Name[1], 22);
FDataStream.Read(tmpByte1, Sizeof(Byte));
FDataStream.Read(tmpByte2, Sizeof(Byte));
FHeader.SampleHead[I].Length := (tmpByte1 * $100 + tmpByte2) * 2;
FDataStream.Read(tmpByte1, SizeOf(Byte));
If tmpByte1 > 7 then
FHeader.SampleHead[I].FineTune := tmpByte1 - 16
Else
FHeader.SampleHead[I].FineTune := tmpByte1;
FDataStream.Read(FHeader.SampleHead[1].Volume, SizeOf(Byte));
FDataStream.Read(tmpByte1, Sizeof(Byte));
FDataStream.Read(tmpByte2, Sizeof(Byte));
FHeader.SampleHead[I].LoopStart := (tmpByte1 * $100 + tmpByte2) * 2;
FDataStream.Read(tmpByte1, Sizeof(Byte));
FDataStream.Read(tmpByte2, Sizeof(Byte));
FHeader.SampleHead[I].LoopLength := (tmpByte1 * $100 + tmpByte2) * 2;
end;
FDataStream.Read(FHeader.SongLength, SizeOf(Byte));
FDataStream.Read(tmpByte1, SizeOf(Byte));
FHeader.TotalPatterns := 0;
For I := 1 to 128 do
begin
FDataStream.Read(FHeader.Order[I], SizeOf(Byte));
If FHeader.Order[I] > FHeader.TotalPatterns then
FHeader.TotalPatterns := FHeader.Order[I];
end;
end;

procedure TOpenModPlayer.Open(FileName: String);
Var
Val: String;
begin
If Opened then
begin
FDataStream.Free;
FDataStream := TFileStream.Create(FileName, fmOpenRead or fmShareDenyNone);
end
Else
begin
FDataStream := TFileStream.Create(FileName, fmOpenRead or fmShareDenyNone);
FOpened := True;
end;
Val := Verify;
If (Val = 'M.K.') then
begin
FHeader.Channels := 4;
FHeader.Verified := True;
Load;
end
Else
if (Val = '6CHN') then
begin
FHeader.Channels := 6;
FHeader.Verified := True;
Load;
end
Else
If (Val = '8CHN') Then
begin
FHeader.Channels := 8;
FHeader.Verified := True;
Load;
end
Else
If (Val = '10CH') then
begin
FHeader.Channels := 10;
FHeader.Verified := True;
Load;
end
Else
begin
FHeader.Verified := False;
FDataStream.Free;
FOpened := False;
end;
end;

procedure TOpenModPlayer.SetChannels(const Value: Integer);
begin
FHeader.Channels := Value;
end;

procedure TOpenModPlayer.SetModName(const Value: String);
begin

FHeader.Name := Value;
end;

procedure TOpenModPlayer.SetOpened(const Value: Boolean);
begin
FOpened := Value;
end;

procedure TOpenModPlayer.SetSample(Index: Integer;
const Value: TSampHeader);
begin

end;

procedure TOpenModPlayer.SetVerified(const Value: Boolean);
begin
FHeader.Verified := Value;
end;

function TOpenModPlayer.Verify: String;
var
tmpStr: String;

begin
If Opened then
begin
FDataStream.Seek(1080, soFromBeginning);
tmpStr := StringOfChar(' ', 4);
FDataStream.Read(tmpStr[1], 4);
Result := tmpStr;
end
else
Result := 'No File Open';
end;

end.

WILL
24-12-2003, 01:35 PM
Looks good so far. I still have to take a better look at her though. I just got home from work and am dreadfully tired. :P

One quick point though; Shouldn't TOpenModPlayer be TOpenModMixer instead? being as Player implies that it will actually play it back, where as we are making this object our mixer? The difference from what I've always known was that a mixer is the section of code that renders all the sound and the player is the part that feeds it all to the soundcard. Just my 2 cents. :)

wilbur989
24-12-2003, 03:01 PM
One quick point though; Shouldn't TOpenModPlayer be TOpenModMixer instead?

Yea I thought about that but for this first thing it acually will be a player. In the play area I just plan on handing the mixeed samples to PlaySound. Once I know that it works I'll start on making the sound interface for drivers.

-Jeremy

WILL
24-12-2003, 10:42 PM
Well so long as we keep the mixer and player units seperate from each other, we won't run into problems when people will want to use the one, but not the other.

With this we could make a playback component that uses OpenAL to playback using our OpenModMixer Unit, and if someone wanted to make a DirectX/DirectSound or DelphiX component they could do it themselves quite easily with just the OpenModMixer.

noeska
25-12-2003, 05:47 PM
yes a layer between the mod player and the directx, openal etc.
maybe the oooal.pas unit is usefull as a start for that. (it now only supports openal, but it can be adjusted to directx and sdl also).

Also a merry christmas!

wilbur989
26-12-2003, 03:50 PM
Well so long as we keep the mixer and player units seperate from each other, we won't run into problems when people will want to use the one, but not the other.

With this we could make a playback component that uses OpenAL to playback using our OpenModMixer Unit, and if someone wanted to make a DirectX/DirectSound or DelphiX component they could do it themselves quite easily with just the OpenModMixer.

Yup and that is the Current plan. Right now All that the above code does os load, not much else. After I the loading working fully I will make sure that Load and play are seperated into a Data/Player Driver Format. :-)

-Jeremy

wilbur989
29-12-2003, 10:30 PM
Well for all of those who are interested in contributing to the Mod units The SF project is finally setup. I will be spendinf the next couple of days working on getting the page worked out so that it has a project home page. If you want to go to the project page the Unix name is openmodpas. OpenMod was taken for an unrelated project. Anyways ttyl :-)

-Jeremy

Harry Hunt
30-12-2003, 08:35 AM
I don't want to sound like an ass, but: Using smart-tabs to indent your code as well as capitalizing the reserved words "Property", "If" and "Else" is not conform with the borland object pascal style guide. Whenever several people are working on the same project, I think it's essential that they all format their code the same way for greater readability. So go to

http://community.borland.com/soapbox/techvoyage/article/1,1795,10280,00.htm

and take a look :)

Also, I think instead of starting to code right away, you should "plan" your objects first. Your project will become quite big and if you don't decide on an object structure first, it can get quite messy.

Anyway, good luck!

WILL
30-12-2003, 09:50 AM
Mr. Hunt makes some very good points, guys. I don't know how well I've managed to follow the style guide, but we should indeed plot out our object model for the library before proceeding with the code.

:idea: I was thinking of us seperating the different MOD types(MOD, S3M, XM, IT, etc) into their own individual object with it's own LoadFromFile() and Render() functions and uses a Mixer Object(the object that does the actual mixing of the audio) to play it back.

And we then build a Super-MOD object that will load any one of these other mod types and render the audio output the exact same way only using extentions of the individual mod types. We can work out different mixer objects if we choose to go that route too I guess.

What do you guys think on this?

Harry Hunt
30-12-2003, 10:16 AM
Okay, just so you guys don't have to read through the whole style-guide:

Wilbur: Don't capitalize reserved words. I see you're capitalizing some and begin other with a lower-case letter. So just spell any word that the delphi editor displays bold with a lower-case character.

WILL: "Record" and "Array" are reserved words, so don't capitalize these. Also, don't use smart-tabs and set your tab-width to 2 spaces (or simply don't use tab at all and indent with spaces).
Also, in array declarations:
MyArray: array [1..4] of Char;
instead of
MyArray : Array[1 .. 4] of Char;

the space after the word "array" is optional. Also, a lot of people declare variables like this:




var MyVar : MyType;
AnotherVar : AnotherType;
YetAnotherVar : YetAnotherType;


the proper way of doing it is:



var
MyVar: MyType;
AnotherVar: AnotherType;
YetAnotherVar: YetAnotherType;


so don't use extra spaces to bring the variable types on the same level and there is no space before the colon ("MyVar: ..." isntead of "MyVar : ...").

Well, maybe I'm overdoing it a bit, but I found it to be very useful to closely follow the style-guide. Obviously it's up to you though.

wilbur989
30-12-2003, 03:06 PM
Wilbur: Don't capitalize reserved words. I see you're capitalizing some and begin other with a lower-case letter. So just spell any word that the delphi editor displays bold with a lower-case character.

Thanks for pointing that out :-), accually I worked at a place that focused on the borland styleguide it's just been a year and I've been getting lazy about following it. But thanks for pointing it out anyway.


I was thinking of us seperating the different MOD types(MOD, S3M, XM, IT, etc) into their own individual object with it's own LoadFromFile() and Render() functions and uses a Mixer Object(the object that does the actual mixing of the audio) to play it back.

My thoughts where close to the same but more like Loader Class takes a filename and detects which format to use and creates a Format Class(i.e MOD, XM, IT, 669, Whatever) The loader has all of the data stored in memory and calls a render method that creates a player class that will send the channel data to a renderer class that will have it own internal mixer as needed. I.E. If I create a windows sound renderer that renderer will have a mixer in it to mix into the stereo output. In other cases like OpenAL that renderer only has to initalize OpenAL and pass the channel data unmixed to it for rendering, as it handles it in OpenAL. But the overall component to be placed on the form should be either a Loader or Player. Any changes to that structure?

BTW I already have thrown out most of the component code above after realizeing there was a better way to handle it.

-Jeremy

noeska
30-12-2003, 09:22 PM
I gues i have a look at the styleguide.
Also i did a rewrite on the modplayer letting it use oooal.pas. That way it should be less dependend on openal for playing mod files.

When can we get access to the openmodpas project site. I think it is better to continue our discussion there.

Some ideas to follow:
Use classes wherever possible like

TModuleData //generic module data storage class
-TITData //inherits from TModuledata but for It
-TMODData //etc

TModulePlayer //generic module player
-TITPlayer //inherits from module player??

TSoundMixer //like oooal.pas
-TOALSoundMixer
-TSDLSoundMixer

Also TModuleplayer is the boss and uses TModuleData and TSoundMixer to play the mod file.

wilbur989
31-12-2003, 05:16 AM
TModuleData //generic module data storage class
-TITData //inherits from TModuledata but for It
-TMODData //etc

TModulePlayer //generic module player
-TITPlayer //inherits from module player??

TSoundMixer //like oooal.pas
-TOALSoundMixer
-TSDLSoundMixer

Also TModuleplayer is the boss and uses TModuleData and TSoundMixer to play the mod file.

That was the clarity I was looking for. If anyone has any other ideas now is the time. Also I can now set up users for SF CVS. Tomorrow I'll be working on a design doc and will have the forums and mailing lists setup. If onyone would like to hack a quick Web page it would be appreciated. I can do the basic stuff but Graphic design is not my cup of tea. :-)

A Side note on the player. Sense it is the master component it will be rather generic and not have to be format specific but the Data object or Loader object will. Also one thought I had was to store the data once in a MemoryStream then just have references pointing to parts of it in the Data or loader object. Once in memory why duplicate the values :-)

-Jeremy

Harry Hunt
31-12-2003, 10:06 AM
Some ideas:
Call your base-classes "TCustomSomething" to make it more obvious that they are, well... base-classes :p

Instead of writing a player class for each module format, have the TModuleData component pass the same data format to the TModulePlayer component for all module formats you are going to support. That way if you want to add support for new file formats to your components, you'll only have to write one component instead of two.
EDIT: duh! Wilbur already mentioned this. Sorry!


Put each TModuleData component in a separate unit.

Keep in mind that you might want to add support for streaming audio formats in the future (MP3, OGG, WAV, WMA, etc.) so make sure that you won't get into trouble if you decide on writing a TStreamPlayer.

just a bunch of ideas :)

noeska
31-12-2003, 05:19 PM
i did a quick write on the class structure i thought up.
i now wrote it into some units and a dummy player.
Also i suggest we keep different players because it, s3m and mod might require some different playback techniques. So as glue i introduced an TModuleManager class.

Download http://www.noeska.com/downloads/classtest.zip to see how i put things together. I am not happy with it, but it does the job.

For now i am looking for a freeware uml tool.

wilbur989, could you add me as a user to the openmodpas sourceforge site.

wilbur989
31-12-2003, 08:26 PM
could you add me as a user to the openmodpas sourceforge site.

No problem. One thing I forgot to mention though you need to go to sf and create a user for yourself then I can add you to the project. It's not a long process just takes a sec to do. :-)


Also i suggest we keep different players because it, s3m and mod might require some different playback techniques. So as glue i introduced an TModuleManager class.

I can't really see a need for seperate palyers only because that if you create the proper Format/Loader class you automatically can hadle any quirks about the seperate formats in one player. The player itself is really just a bunch of glue code because all of the work will be handled in the other renderer classes. All the player should have to control is messages and data to pass to the renderer. At least that is what I see. :-D I'll take a look at the code tonight.

Thanks for your thoughts. This is how the design process should work. Come up with a common solution and go with it. :-)

-Jeremy

WILL
03-01-2004, 01:24 AM
Happy New Year everybody. :) Sorry about the slowness of my post, I was in Ottawa the past few days celebrating.

I think on top of the TSDLMixer, TOALMixer, TDirectSoundMixer and TEAXMixer, etc... we should have a TIntelCPUMixer, TAMDMixer, etc... Using simply only the CPU and inline-ASM for mixing not any special hardware or libraries. This might even be a faster choice if someone wanted to make a player or a tracker themselves.

:idea: Remember, if you can, how you would playback a mod(ie. *.IT) in one tracker(or player ie. WinAmp) and it would come out different from the tracker(ie. Impulse Tracker) you composed it in? I suggest we ty to be truest to the original Tracker's 'sound' for our playback. This will help maintain consistancy throughout the project with the existing standard. :idea:

Hmm... MO3 support(mods with MP3 encoded samples), might not be such a bad thing either. It would be no different from supporting zipped or rared mods(something that we could support too in the distant future).

I've gotten my S3M loader to the point of loading the sample data. Right now it loads the header, verifies that it has the 'SCRM' tag, loads Channel Settings, loads Orders, loads ParaPointers, loads Default Pan Positions, sets Mono status and loads the Instruments. The only thing remainning is to load the sample and pattern data. I've actually discovered that there are some tricks to loading these mods. Hopefully XM and ITs will be far less messy.

If I have an empty class to stick this once the framework is established then I can stick it in there and send it.

noeska
03-01-2004, 09:06 AM
This thread is growing to large and to many sub topics are inside it.
As the openmodpas sourceforge project is alive it it best to use the forum inside it there: http://sourceforge.net/forum/forum.php?forum_id=340896 . To post messages there all that is needed is a sourcefourge account.

WILL
03-01-2004, 11:09 AM
Yeah, this thread is getting quite big now. Not that the DGDev Staff minds. :) But I have added a few comments to the sourceforge forum for openmodpas and have sent in a request to join the openmodpas team. So when wilbur989 signs me up I'll be able to add some of the stuff I have been working on for it, of course providing we have finished and agreed upon the structure of the base class we will start out with.

wilbur989
03-01-2004, 04:15 PM
I agree this has gone on log enough here. For those interested in adding there two cents in on this project please go set up a sf account and post on the forum link givin by noeska. I you would like to become a memner of the team just send me a message through sf after you set up your account there and I'll set up up as a developer in the project. :-)

Thanks for all of those who have givin there input. All of the different views help a project like this get bigger and better.

-Jeremy

TheLion
06-01-2004, 08:50 AM
I just browsed through the pages of this thread really quickly and found it way too late (must have missed it while reading the forums). However I still wanted to make a little post. :)

First of all I think what you guys are planning is a GREAT idea! :) I started working on some experimental sound engine for the DGDev Team using OpenAL. One of the things I wanted to try was to play module files, however all the information I could find on it was on the file-structure and some really outdated examples in C++ which didn't work anymore most of the time. All the other OpenSource projects in C++ like MikMod, where very hard to read for me and somehow I couldn't find where everything was done (man I hate C++). I managed to make a player using all the bad information I had and an Example that was on a Delphi OpenAL page (think it was Noeshkas).

I want to ask you guys to keep this project Pascal (Object Pascal) only, since there are a lot of C++ examples that use a lot of ASM code and since I can't read ASM, those projects scared me off and where totally useless for me.

However like I said, I think it's a great project, since this is one of the things the Delphi Game industry really misses! :)

P.S. I'm not sure if you guys still have some spots open, but I'm willing to contribute to this project, however I don't have a lot of time on my hands.

wilbur989
06-01-2004, 05:02 PM
There are as many openings as people want to join. In other words Welcome! :-)

As to implimentation, I want to use as much Object pascal as possable. When interfaeced into OpenAL it will not need any asm at all. But when interfaced just as a sound stream it may need some mixing code which could very well only work as ASM. But we will be avoiding it as much as possable.

-Jeremy

WILL
07-01-2004, 06:23 AM
I can tell you right off the bat that there will be ASM mixing code. Sorry non-ASM coders. :/ But, this will be mostly to speed up non-OpenAL/DirectSound/EAX, etc mixing functions.

BTW, I managed to coin a copy of the libmodplug C++ library(C compatable) source from a ModPlug XMMS plug-in while I was tinkering with XMMS in Linux. It has full source of the ModPlug loaders and mixers. Something that did not exist publicly until now. ;)

Drop me an email and I'll send it to you. It's rather small. Its code is based off of the ModPlug Sound Engine, but it has been modified since, I'm sure it will be quite a valuable resource for help with OpenMOD :)