Mod Archive Forums
Music Production => Players => PC Players => Topic started by: Sto on March 11, 2011, 04:20:50
-
Hi there!
I'd like to present you my now 2-years old project called "PeePeePlayer" (I hadn't any name, so I decided it to call it like my initial project folder was named: /ppplayer).
It aims to look like good old DOS, but with modern algorithms/code under the hood. It currently plays only s3m modules, but I have spent much time to reproduce screamtracker behaviour of the effects (please compare "Satellite One" by "Purple Motion" with other players), and at the moment it seems that I've got the most "original" sounding player for those modules.
Basic loading code exists for XM modules, but there are still a few things I have to do on the GUI (mostly performance). Please give it a try.
Code: http://peepeeplayer.sourceforge.net
Comments are welcome!
-- Sto
-
Holy... that looks cute. :) Only tried without sound so far, though. A new S3M player is a bit unexpected in 2011 and while it seems you're already starting on the rocky XM path, tell me this: Are there any plans to support Adlib channels in S3Ms? Maybe via DOSBox or MAME's OPL emulators? Because that's what I think modern players could really use.
-
There are still plans to add OPL3/FM emulation to the player, but unfortunately I have absolutely _nothing_ to check if the emulation is right. I have only found one module that actually used these instruments, but the problem is that it sounded different on every emulator I tested, and the oldest PC I still have has an ESS Maestro which I cannot replace (it's a laptop).
So... plans are not dead, but they're on the bottom of the todo-list.
-
I have only found one module that actually used these instruments
Only one (http://www.exotica.org.uk/mediawiki/index.php?title=Special:Modland&md=for&id=53)?
SchismTracker has (still kinda unstable) support for Adlib S3Ms, so you could take a look there as well if you don't know how to do things.
-
I actually looked there some time ago, but I got really confused, and the loaded module sounded absolutely wrong (though I don't know how it would sound right...). I have found the YMF262 docs yet, and I am taking another look at it. I think I'm going to write an emulator from scratch.
// EDIT: And there were some code quality issues, mostly maintainability that made me refusing the sources I found.
// EDIT 2: I have achieved very valueable information about the OPL2 now (thanks Google!), and I am now - at least in theory - able to build a accurate emulator.
-
Sorry for double posting, but I need some (mathematical) help. I have written the OPL phase generator code now, but I cannot figure out why my code produces a sine wave with an amplitude of 64 while the volume (0..63) is set to 0.
The octave code I am using is here: http://pastebin.com/rbqKRyms - you may run it directly and see what I mean.
Thanks if anyone can give me a hint.
// EDIT: forgot to mention https://docs.google.com/Doc?id=dd8kqn9f_13cqjkf4gp
-
Shame on me for triple-posting :-[ but I got some news and a request.
First, I got XM support that seems to work well but is still missing some features/effects.
Second: I need testers for the XM support, because when I merge the xm branch I'd like to announce PeePeePlayer 0.1.2-beta, and I need bug testers to get rid of the most annoying bugs before that.
Grab the sources here (http://peepeeplayer.sourceforge.net) (remember: use branch "xm").
Thanks in advance,
-- Sto
// edit: merged into master: (http://i51.tinypic.com/25pn5er.jpg)
-
After a many hours of work I'd like to make a stress test: can anybody recommend an XM module that only plays well in FT2? The reason is that I have rewritten nearly the whole XM logic since the last time I posted and it seems to be quite good now, but I'd like to also test the corner cases. So far I have only found Kingdom Skies from JaseChong (http://modarchive.org/index.php?request=view_by_moduleid&query=44452) that got me into trouble :)
Thanks in advance,
-- Sto
-
Although many of my tracker test cases (http://wiki.openmpt.org/Development:_Test_Cases/XM) were written with bugs in OpenMPT in mind, they are maybe useful for verifying the correctness of your own player.
Compared to an actual composition they have the advantage that it's easy to determine whether they are played back correctly or not.
-
Thanks, I remember visiting that page ages ago, unfortunately I forgot it :rolleyes:
-
Hmm, that particular page was created about three weeks ago, not too long ago actually. ;D It's heavily inspired by this (http://schismtracker.org/wiki/Player%20abuse%20tests) page, though, so you maybe had that in mind.
-
Yes, you're right, thanks. It's hard to check the tests, but at least I definetly pass the "infinite loop" test ;)
// Edit: Around 40% passed, and 20% partly passed, seems like I've got some work to do...
-
Yes, you're right, thanks. It's hard to check the tests, but at least I definetly pass the "infinite loop" test ;)
Which parts in particular are hard to check? I want this test suite to be as easily usable as possible, so if you have any suggestions on how to improve some tests, please do tell.
I know some of the older test cases are not very good and the descriptions are probably even worse, but if I know which ones are difficult in particular I will focus on improving these.
-
Which parts in particular are hard to check?
The problem is simply that I cannot really debug my player, I am currently comparing the results of FT2 and the generated mp3's.with my ears, though I am already thinking about how to automate this (e.g. write as WAV and see how this differs to the original one). The main problem is that I never used FT2, and that some of the XMs are quite fast or have pretty random things within it so I can't tell if the result is OK or not.
I think it would be cool if some musician would sit down and combine all the corner cases into one cool track so that it's easier to tell when something sounds wrong ;)
// Edit: OK, most of my post is completely stupid, I haven't read the text on the page and only downloaded the mods, so ... my fault, sorry.
-
I think it would be cool if some musician would sit down and combine all the corner cases into one cool track so that it's easier to tell when something sounds wrong
That has been done before and believe me, it's the worst way to determine whether something is correct or not. First off,you have to sit through the whole damn thing to check whether everything plays correctly. And secondly, you can not exploit every bug in a way so that it is extremely obvious that it is played back correctly.
I think playing back the (suppsedly) same stuff on the left and right channel is a far better way (in all cases it should be really obvious if your player does something wrong), and if the test is too fast, you can always render it to WAV and play it at half the frequency or something. And yes, the description texts are important to get an idea what the test is all about and what it should sound like.
-
I'm sorry for the not so good things I wrote, I was pretty tired, and an average room temparature of 27 degrees celcius due to the summer were the reasons for that. But back to topic: I wrote a small python script to automatically compare two WAVs, so that the testing could maybe automated (I recently added WAV export for that): http://earvillage.square7.ch/downloads/wav_compare.py - maybe you could use it for openMPT as well.
-
That sounds very interesting, I'll have a look at it. I previously had the same idea to automate test case verification, the only drawback is probably that it relies on the render settings (interpolation and the like) to be exactly the same every time you run the test.
-
Well, I discovered a major issue... my player's output is 2 times louder than the ft2 output, but the tool shows only a difference of 0.4%. Additionally, it is pretty slow (nearly realtime :(). I think I will write a small cpp to gain more speed and to be able to add some additional parameters like multiplying the samples from one .wav with a factor or the tuning of the comparison method (like "ignore length diff" or switch between mean difference and root mean square).
-
Well, I discovered a major issue... my player's output is 2 times louder than the ft2 output
You could of course normalize both outputs.
-
You could of course normalize both outputs.
... which would definetly fail if there are some peaks in the output. The worst case would be a module where i.e. one envelope is calculated wrong so that one note gets played very loud - which is clearly wrong, but only one factor out of many, and here normalization would create a false positive as the difference between the waves would then increase. In my opinion that's a no-go, but I'm open for ideas.
-
So... I have spent some more time investigating the disassembly of my dosbox memory dump and discovered that I had done some things terribly wrong, now I understand what is it all about Jeroen Tel's XMs :)
Though I haven't yet started with the planned WAV comparer, I know that my player works much better now, but before I start with the comparer I want to solve the infinite loop problem, which shouldn't be that hard to implement.