OpenSource Object Pascal Module Playback Library

[noeska]

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]

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]

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]

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]

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]

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]

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]

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]

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