[PROJECT] ProTracker v2.3D clone for modern platforms

[8bitbubsy]

I'll bump this by saying that *everything* is now implemented in my PT2.3D port (except one single thing: split key mode. CTRL+S is now used for quick saving). After coding for countless of hours, it's finally getting near a stable release, but it also has these non-PT bonuses:
- A WAV sample loader/saver with support for loops/name/volume chunk attributes from sampler exported WAVs (or from OpenMPT)
- *proper* STK (Ultimate Soundtracler) loader (effects/sample loop types)
- Loading of PowerPacker'd MODs (this was in PT too I guess, but I list it anyways)
- Full bug-free support for 128kB samples (many tracker UI functions in Amiga PT crapped out when ran on >64kB samples)
- More keyboard keys handled (e.g. HOME/END/PAGE UP/PAGE DOWN in several things)
- MOD2WAV for exporting the song to .WAV (with switchable filters, hard pan and band-limited steps for Amiga-ish sound)
- PAT2SMP for rendering the current pattern to a sample (for making drumloops etc)
- Sample hand editing tool (for drawing chiptune styled samples or fixing clicks in samples, etc)
(read help.txt in the zip for more in-depth information about the new stuff)


Also a million bugfixes and speed optimizations were added since 2011. :-)

http://16-bits.org/pt.php

(could an admin/mod change the thread name to "[PROJECT] ProTracker v2.3D clone for modern platforms"?)

[Dunny]

Sent you a message on SF, but don't know if you got it.

Any chance for Song format to be supported? i.e, store samples separately to music data. Would make porting this to the Pandora much simpler and more logical than storing samples multiple times inside the mod files...

Cheers,

D.

[lesta_smsc]

Where have I been when you were developing this?! Just tried a conversion of Lotus 2 module and it sounds great! I love the interface! Keep up the good work!

[8bitbubsy]

Originally Posted by Dunny

Sent you a message on SF, but don't know if you got it.

Any chance for Song format to be supported? i.e, store samples separately to music data. Would make porting this to the Pandora much simpler and more logical than storing samples multiple times inside the mod files...

Cheers,

D.

It took me a week to see it as it got stuck in my spam filter, anyways I replied to you a few days ago, didn't you get it? I said no btw, because it would be a huge hack just to support some hardcoded ST-xx volumes...

EDIT: Why would it make porting simpler and more logical this way? 95%, if not more, of all spread modules were MODs with the sample data inside them, and they range anything from 2108 bytes (absolute min.) to 4166654 bytes (absolute max, 100 patterns and 31x 128kB samples). MODs are usually well under the 1 megabyte range, shouldn't create a disk space issue.
There is nothing that tells me that creating a system that "magically finds" non-existing ST-xx volumes is logical and easy on a modern machine. Not to mention that creating the "song" system just to support the ST-xx packs would be a waste, and these are the only sample packs that I know the volume names of... It would be a non-portable hack

[Dunny]

Originally Posted by 8bitbubsy

It took me a week to see it as it got stuck in my spam filter, anyways I replied to you a few days ago, didn't you get it? I said no btw, because it would be a huge hack just to support some hardcoded ST-xx volumes...

EDIT: Why would it make porting simpler and more logical this way? 95%, if not more, of all spread modules were MODs with the sample data inside them, and they range anything from 2108 bytes (absolute min.) to 4166654 bytes (absolute max, 100 patterns and 31x 128kB samples). MODs are usually well under the 1 megabyte range, shouldn't create a disk space issue.
There is nothing that tells me that creating a system that "magically finds" non-existing ST-xx volumes is logical and easy on a modern machine. Not to mention that creating the "song" system just to support the ST-xx packs would be a waste, and these are the only sample packs that I know the volume names of... It would be a non-portable hack

Ok, no problem. I'll add it myself - shouldn't be too hard to manage.

D.

[Bastich]

Great project

[thinlega]

This looks a really interesting project! Nice one dude

[8bitbubsy]

Thanks for the kind words!
Dunny: Please share the result code if it turns out good... I have no good idea on how to support named volumes in the SONG format and how to "redirect" it to ST-xx folders.. And what should it say when it looks for the ST-xx files, etc? Sounds very hackish to me.

[Dunny]

Originally Posted by 8bitbubsy

Thanks for the kind words!
Dunny: Please share the result code if it turns out good... I have no good idea on how to support named volumes in the SONG format and how to "redirect" it to ST-xx folders.. And what should it say when it looks for the ST-xx files, etc? Sounds very hackish to me.

Well, I'm going to surround the code in defines specifically for the Pandora - the filesystem means that the samples will be in known locations and not moveable by the user, which makes things much simpler.

I'll let you know when I'm done - will be a while yet as I have a couple of other projects ongoing at the moment.

D.

[8bitbubsy]

Huge update: My PT clone now doesn't instantly crash anymore on some Intel Mac systems running OS X.

[tolkien]

Would like to compile it for MorphOS. What are the requirements to compile It?
I have tried it but I'm stuck. Can It be compiled with -noixemul?

[8bitbubsy]

You need a development library called SDL (version 1.2.x, important). That's it! There might be some #ifdef incompatibilities with MorphOS, especially in pt_config.c (the "get executable path" hack stuff, can be commented out).

I'm not sure if you need to pass some flags to the compiler, I have never tried to compile it for MorphOS before. Try to look in make-linux.sh. Also, make sure you got the very latest code first, execute this command in the shell (make sure you have SVN installed):

svn checkout svn://svn.code.sf.net/p/protracker/code/trunk protracker-code

[tolkien]

I have SDL sdk installed and have downloaded latest code. i have made a few modifications but I'm stuck with realpath().
LibNix in MorphOS supports It but I have an undefined reference.
Must look further in pt_config.c

Thanks

[8bitbubsy]

There's a chance that removing the hack still makes it able to find protracker.ini/PT.Config-xx in the same directory as the binary. It's a hack I did because apparently there's a bug in SDL 1.2 in some scenarios where it changes the current working directory to outside of the binary on program run...

Try replacing pt_helpers.c with this this (this is the only file needed to change, it has the hack function): http://pastebin.com/HBHxsNr7
Ideally I want to get rid of pt_helpers.c, it's a mess not needed.

[tolkien]

Hey! Thats works! I can compile and run It. I thinks need a tweak in the color format cos is a bit blue but is working!



EDIT: Have problems with loading modules. Seems can't change directory nor select a mods. Step by step...

[8bitbubsy]

Yeah, the pixel buffer is hardcoded to 32-bit ARGB format, not all systems might like this. Try to run both the OpenGL version and normal version? To compile the OpenGL version, pass USE_OPENGL as a preprocessor flag to the compiler, check make-linux.sh for this.

[tolkien]

My MorphOS setup can only be 24-bit max so perhaps is that the problem although I have tried an older version and It shows well.
I have compiled with OpenGL but I see the same matter.
The worst problem is that the disk operation doesnt work. If I load a .mod through command line the mod loads and plays good but can't save.
All functions seems ok...only diskopt ones doesn't work.
Need to look carefully.

EDIT: I have replaced diskop functions with asl requesters to load mod. Need to finetune it a bit and understand all pt_mouse.c source.

[8bitbubsy]

Ouch, guess I need to install MorphOS on one of my PowerBook G4s and have a good look.

All bitmap pixels need to be normalized with some SDL function on init. I don't do this yet, but I will get to it one day. Most of the datas are stored as 2-bit palette values, so I already iterare through every pixel (except raw 32-bit bitmaps) on init to convert them to 32-bit ARGB using the palette LUT.
Then I will also have a look at using realpath() and some modified disk op. code if MorphOS is present. This will not happen soon, but I'll maybe look at it this weekend.

[tolkien]

I can use it at its current state. This was an exercise to me as I'm learning to code and port things but as a musician I would like to have such a classic on morphos.
Thanks for the project and the help.

[8bitbubsy]

No! This has to be fixed, this is not acceptable. ;-)

Just as a test, open up pt_palette.c and change all values in palette[] from 0xFFxxxxxx to 0x00xxxxxx. For example 0xFF888888 to 0x00888888. Then compile and run, and link a screenshot... Maybe your system wants the framebuffer pixels in BGRA/ABGR instead of ARGB. Alpha is most likely not used at all, but it's a quick test.