OpenSource Object Pascal Module Playback Library

[noeska]

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]

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]

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]

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...5,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]

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]

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]

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]

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]

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]

Some ideas:
Call your base-classes "TCustomSomething" to make it more obvious that they are, well... base-classes

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