A quite interesting thing is happening right now: two people want to implement the OPL3 emulator code in hardware. I find this very, very exciting, as I never imagined somebody would actually try it; and I never though that anyone would actually use the code of PPPlay as a reference. You may follow the progress here.
Wohoo! After about 2 years of work, I finally managed to get a pretty stable release again. There has happened so much that I decided to rename the project from the offending
PeePeePlayer to the original project name: PPPlay. It was a nearly complete rewrite again (sigh!), but the code is much more stable and cleaner than ever. Hopefully this attracts some users, or better, some programmers. It's fun again to work on PPPlay after this big achievement.
Good news! The OPL3 emulation code is making great progress - with this java code as a base, integrating the log-sin discovery, reducing the floating point math to simple bit manipulations and great help from this forum, I finally managed to get some pretty good results. You can directly compare a real capture and the emulated output (left is emulator, right is youtube). But the code is still in an early state and it will probably take some time until it is ready to be released into the wild. Unfortunately, I don't own an OPL3, so I have to rely on the captures of others, but these others are hardware guys and have much better knowledge of how hardware is working.
The final words: I will release the OPL code under the LGPL so that it is easier to be used in other projects (I'm thinking especially of DosBox and ScummVM).
I just wanted to inform you that I'm heavily working on OPL emulation. I already worked hard on the logic and math, and now I have some code put together that does not use any floating point arithmetic at all. Does it work? I don't know, but I am already writing a HSC plugin to test the code. The code is not online yet, as it is nothing that meets my quality standards. Especially the HSC plugin needs work as it is only some hacked AdPlug code. However, I'm still working on it
I recently pushed some heavy changes and updates into the repository, including:
- WAV and OGG export
- XM player logic rewrite and bug fixes
- S3M bug fixes
Unfortunately, there are still issues in the XM player logic, especially when it comes to infinite loops. There are some test cases available, but be sure to have your task/process manager open when testing them
Additionally, forward seeking causes a deadlock which I still have to trace down. There's still so much work to do...
Bad News for the moment: I implemented linear sample interpolation!
This was something I thought I'd never implement. It's a "fancy" thing, something that doesn't sound "original". But there is a simple fact that I realized now: interpolation lets modules sound better most of the time. I am currently reworking the mixer logic so that the user can switch between several interpolation algorithms, but the default will be linear interpolation - which is (I think) a good compromise between quality and an original sound.
Another thing is that I am (again) rewriting the XM player logic. The problem is that the logic I've written before had too many hacks inside, resulting in a bad maintainable code. The bad news about this is that the logic is partly broken, leading to modules being played wrong.
I expect to fix most of the problems next week, as the Semester is finally over and I have a week off.
I just wanted to say that I am not a C++ professional. PPPlay started as a personal challenge to start programming in C++, and nobody was there who actually told me how to do it. Looking back, I didn't even use educational books, though I am the proud owner of some of them - I taught everyting myself, and I did many many wrong things and had many many wrong assumptions.
And that's the root of all evil: I had no big clue when I started the project, so today I am mainly reviewing and rewriting old code. You will see that in the early commits I did many mistakes, and according to Ohloh I did about 4 or 5 complete rewrites, spread over about 400 commits (also counting the lost SVN commits if you wonder about the number). This is still a personal project, and I don't have any (well, to be honest, not much) feedback received yet, though I'd be happy to get some.
I think I have reached the point where I do not worry about the language anymore that much, but where I worry about logic and design - you can see that on my attempts to implement multiple threads and the evolving split of the Module Model and the PPG View. Learning is a hard, long, rocky way, but it's great to see how my "child grows mature", and my efforts are worth that - I hope.
Just in case there's anyone out there who's actually reading this: I am currently working on thread safety and moving common code to the base classes. It's not going that fast as I wish, but I have to learn for the tests at the university. The code I'm working on got more stable in some places, while other places do make trouble now. Let's see how it goes
Update (April 6th)
After some heavy work, I got promising results from the refactoring: PPPlay doesn't crash that often anymore when exiting, and data races seem to be gone completely. As a side effect, the API got cleaned up a little bit. I will continue to clean it up, so hopefully it will be good enough for other programmers to jump in -- in a distant future...
It's been some time since the last release, but there are many things going on. At first, the new version will include full XM and 31-sample MOD support (15-sample MODs are a bit trickier to detect, but chances are still there that PPPlay will support them). Please note that it is still far away from beta, but much more far away from alpha, so it will take some time until the first beta appears, though (if you are an adventurer) you may download the bleeding edge sources...
To give you some more hints about what happens, here is the regularily edited, messy draft of the changelog:
- Fix: Delayed video refresh caused sound to hang
- New: XM Support
- Change: Rewritten Sound routines nearly from ground up
- Change: Command line options
- New: 5-Level logging framework (to the developers: it is independent of peepeeplayer, so you may use it in your own programs)
- Change: No more random crashes, only random safe exits now
- Fix: Tick simulation now properly sets the Bresenham interpolation variables
- New/change: On-demand preprocessing
- Module will not be fully preprocessed on startup, only length will be estimated, boosting loading speed
- Preprocessing happens when manually seeking forward or the order changes
- Thus, initial forward seeking introduces some short delays, but the state is saved so it will be used when seeking backward and forward again
The most stunning point is (in my opinion) the last one. The on-demand-preprocessing reduces startup time heavily. The XM I tested (can't remember which one, sorry) was about 12 minutes long. The old code needed over 30 seconds to preprocess the module and calculate its length, the new code reduced that to under one second, and half of that second belongs to startup code and multimedia initialization.
Thinking about v0.1.4, maybe I'll introduce a "meta-extractor mode", which simply prints the module's playback length and some other meta information to a file or the console so that it can be used by other programs. But maybe I won't. It's far in the future.
Then, as I refactored the Grep Plugin of KDevelop, I got in touch with Git, and began to love it. I moved over to gitorious.org. Again, I did some things very wrong with Git. But gitorious.org is only a source management site, there are no forums, no bug trackers, no mailing lists.
Looking for a better place, I found berlios.de, which hosts my (now outdated) sources for about one year now. But due to lack of money and employees, they'll close their site at the end of this year.
And as I searched for yet another place to host my project, I discovered that sourceforge.net has evolved very well for the last three years.
Yeah. Finally at home (I hope).