Optimized Player 6.1 Playroutine 'p6107.lha'

[pmc]

@ Noname - massive skills man! - superb stuff!

[Photon]

OK, decided to do the 'future wishes' todo-list myself, and implemented nonlev6 mode, and it seems to be working fine. Yes, I have masochistic tendencies.

So now for the first time I've modified the 'main' code (P61_Music start and P61_playtime, mostly) but the changes are not that huge and all are optional.

Will release p6108 when I'm happy with it, I'll be using it in a demo.



When I did the nonlev6 mode, I discovered something sounding like 'uninitialized registers'. Unused voices that had 'continued effects commands from a note started in the last pattern' (common technique to 'wrap' a song and letting sound continue playing to save some patterns/not have to compose an ending ) didn't have their replen/loopptr set in P61_Init. In this case it was because I'd removed the setrepeat lev6 interrupt, but what you describe could be a side effect of the int not getting triggered by the Init. I guess it's not the same, but anyway.

When I also removed the DMAs on int, I noticed that the effects code is indeed executed for 6 frames before the first 'proper' note (first note in first pattern) is played. For a reason, apparently. (One which I have not yet sussed out.) Because I noticed this and set the note frame counter to 'decrunch first note' in Init, and this resulted in a predictable 'squawk' on all modules. It's quite okay to set the counter to run effects for 633 frames before playing the first note all is quite and the module starts correctly. But anything less than 3 frames of 'running effects on empty sound' will give this effect.

It's likely more PT-based players than P61 would have the same requirement, so maybe the Init code in that player had the frame counter set to 'a too quick start'?

[pmc]

Great continued work on the player code Photon.

Originally Posted by Photon

I'll be using it in a demo.

Great news - the oldskool king is back! \o/

Got pointed to this thread by Simply / Parallax and just had to register to the board to express my sincere condolences to anyone who has had to work with my ancient code

It's humbling to notice that people still care about something I wrote pretty much for fun almost 20 years ago. Definitely my virtual hat off for you guys.

// Jarno / Guru / Sahara Surfers

[Photon]

Hehe Well it's not so much about the code itself as the fact that it's someone else's code. It was bad enough when I looked at the relatively straightforward and simply programmed PT players of old, that didn't have compression. But when the code has gone over by others before so there's not many optimizations left, code has been snippetized to distribute over frames, and those snippets snippetized with assembler optimization directives, it's just... extremely annoying to get into and know you have a correct 'vision' of how everything hangs together and exactly what the flags and variables are intended for. That's how it is for me, anyway, others may have an easier time.

But as with everything you get used to it after a while and you get slightly less annoyed. I must say it's nice of you and Noname to express interest anyway


OK, had a look at more channels and synth and did some experiments. First I had to decide the best method and what additions would really give the best/most needed enhancements. I will not implement this until after Breakpoint 2010, I will do the very last optimization on p6108 and release it before I add this.

Since both the coming p6108 and the following synthversion will now have the 'code outside the decrunch routine' changes (unlike p6107), they should be considered as branches from P61. Not that they are experimental or beta, and I've certainly made the changes carefully and tested all modes and options and am using it myself. It's just that it's gone from 'fixing non working seldom used functions and replacing the decrunch routine' to a lot of required changes all over the routine. I've made all changes optional, so if you don't use the new options, it should behave exactly as p6107. But I would be inhuman if some little omission didn't sneak in somewhere to appear in some special module or options combo.



I haven't decided to do the synth version at all, but here's the plan if I do:
1. Composer takes (and if necessary rearranges) a standard PT module to make 1 or 2 channels that have no period changes (includes portamento, slide, vibrato). (Right now the plan is that the selected channels must fill this criteria for the whole song, possibly it could be switched on for the patterns that it's needed, somehow.)
2. Optional, and only if 2 channels used): The instruments used in these channels can now be assigned an 'echo' value (simple sample scaling with delay) by giving a list of instrument numbers and their values to P61_Init. If delay is zero, you get pan, and if scaling is 100% and delay is non-zero, you get chorus.
3. With or without pan/echo/delay: A synth 'plug-in' routine is called from P61_Music, pointers to buffer(s), pointers to echoed sound is provided, and size of buffer and period. Routine simply mixes generated synth sound with optional echo-sound to the buffer(s) and returns.

It uses its own code to fetch notes, but can use the P61 tempo counters and pattern/position counters to sync and read the right note

With 2 extra synth-channels and pan/echo/delay option, this takes 36 scanlines with simplest possible synth (synth routine simply copies a wave, has no code for period/volume envelopes or vibrato or things like that).

Same as above but no pan/echo/delay: 13 scanlines per 'simple synth channel'.

To this time is added the actual synth code to generate something pleasing Buffer size in experiments is 280 samples, but I haven't actually heard anything mixed yet. So if the synth sounds crap when mixed, and increasing the kHz helps, raster time will increase with buffer size.

If the synth routine just copies a sample, it could be a semi-decent way of adding two extra sound effect channels in a game for 13 scanlines rastertime per channel. The two selected channels don't need to be protracker channels, of course, they could be playing sound effects too, giving 4 sound effect channels and two protracker channels.


If someone has a better/faster idea or feedback/want to guide me, or has nice synth code they think can work with this, I'd love to hear from you! PM or email is best.

Now, back to optimizing. I think I can take one more scanline off.

[pmc]

[Photon]

OK, I'm at almost 1.5 scanlines gain now. It's getting exponentially harder as there's less code left to remove or do anything with). A for-sure gain of 1 branch per channel turns out to gain 0 cycles, so revert to good old version and back to profiling. I've focused mainly (there it is again, that word!) on distributing chunks of code rather than clever tricks or 'optimizing every effect' since I want to make sure the changes I do have no side effects that might not get tested properly with the modules I play.

The P61_slen (song length variable) bug was simply that it writes the length+1, and the only reason I didn't find it for the other (length >1) modules was that I had no Bxx/Dxx/SetPosition stuff that jumped to the last pattern in the song in them. It's now fixed to store the correct song length. The reason stepping to next pattern even worked (!) was that it doesn't check song length at all but does the same check as the search in P61_Init, or it would have been noticed long ago I think.

So when I fixed that I tested Bxx/Dxx/Setposition to last pattern and it all magically worked. I love it when that happens

I'm pretty much done, I'll see if I can remove a moveq from the playtime channel loop, possibly make a conditional for the decrunch to save a dbf, and if I have the oomph profile some commonly used effects to see if there's any use having a look at them.

I wrote before that it should be considered a 'branch from p6107' since I've started changing things in the main code. That's not really true now, I've made the distributions of code assembler options and wrote information about their use. The only real issue is if you use 'F01' commands (playingpatternsveryfastinabout1second!), and you can even use non lev6 mode with CIA-timing if you read the docu.

Uhm... Thundercats are GO! Back in a bit.

[Asle]

There's something I don't understand. I'm quoting the doc :

- NOTE!:Patternbreak (D) does NOT support break to a specified
line, linenumber is just ignored! This is due to my packing system.

From what I have seen when playing with this format, is that while the pattern does indeed "ends" when seeing a B** or a D**, it still stores the remaining potential rows if those FX commands are not on the last line (row 64).
But I didn't see/know there was ever a problem with either of the FX, when taking into account this limitation.
Can you explain what was wrong, please ? I'm just curious

Incidentally, my conversion of a P61 keeps the extra never played rows while Gryzor's empties them. That could be another optimization I guess. Though, in output size this time.

As a last note, why not optimizing a Protracker routine ? From a collector point of view, The Player is not great as every strings are lost (title/sample names).

Good works, there, my friend !

Sylvain

[daxb]

BTW. Does support p61 large samples (64kb to 128kb)?

[Photon]

OK, managed 1.6 scanlines, there doesn't seem to be a single thing left to optimize. I think I'll hang onto this version until after Breakpoint, cos I'd like to try a more advanced distribution option for the channel decrunch. But that's more ambitious and I need to spend time on finishing the demo.

Asle, well that quote is for the converter docs, I think. It's been unchanged through many versions of the playroutine, and I just want to do speed optimizations, so I won't change it either.

To be honest (and the reason I optimize this and not some protracker player) is that this seems the standard for demo-making, and so there's no reason to optimize something nobody would use. I think you can take any protracker playroutine and as long as you do "start sounds" and "set replen" as interrupts, you're already faster than The Player 6.1, since the playroutine doesn't have to decrunch the notes!

I actually started my own module compression utility a year back, but when I found out everyone uses The Player and it had decent compression already and a reasonably mature and tested playroutine, I figured I'd put the time into that instead. I'll still use the PT format interpreter in the utility for another project.

Since it has decent compression already, removing notes below Bxx and Dxx commands won't make a big diff. Unless you fill them with random notes that have no similarity to anything else in the song, so they don't get "crunched away" if they are blank or has the same beat/melodies similar to another pattern they will be crunched to just a few bytes. Replay has no problem with Bxx/Dxx even without this size-optimization.

---

Daxb, I've not removed support for anything that p6106.lha (widely used latest version) supports. In short, every advanced option that wasn't used in my test-modules have been left completely untouched. I have added one option that doesn't work with F01 commands (nothing to do with sample size), but each option is explained so you can decide to turn them on or not.

[Photon]

OK, I distributed the decrunch over 4 frames and I went from 1.6 to 3.0 scanlines gain

For some songs, only 2.4 scanlines. The reason is that the frame time is so equal between frames that it's the content of the individual channels that set the max rastertime. If the last channel had lots of notedata and got crunched well, the last frame will take the longest. Can't really start changing the composition to save more cycles, can I?

This "split4" mode is incompatible with songs using tempos of 1 notestep per 3 frames or faster (F03,F02,F01), for obvious reasons. For those fast songs you will get up to 1 scanline less gain. But I'm very happy, I'm now sure there are no optimizations left.

[phx]

Thanks for your work, Photon. It seems that the player is working fine for me, once I configured all parameters correctly (and removed the IF2 directives). I'm really impressed from its well optimized performance.

I'm setting "exec" and "system" to 0 (filling in P61_VBR myself) and using "CIA=1", as calling P61_Music myself during VERTB doesn't work very well with mods, which are setting the tempo (e.g. with "F7D").

Maybe you should consider to ignore an F-command with an argument >=32 (tempo), when CIA=0 ? Now the player sets $7D as speed, which is nonsense.

I would also like to use the "fade" option, but this means four expensive MULUs for scaling the volumes every time. How about a multiplication table for all 64 values (64*64 bytes) ?

[phx]

Is it possible to make P61 play an external effects sample on a single channel, and not playing any new note as long as the effect is in progress? This would be very useful for games.

[daxb]

Indeed! Each mod player should handle this. DawnBringer (e.g. game BabeAnoid) did this in his games and it is a really great feature. Ok it is not ASM, he used Amos. You can have music and sound effects in only 4 channels.

[Photon]

Originally Posted by phx

Thanks for your work, Photon. It seems that the player is working fine for me, once I configured all parameters correctly (and removed the IF2 directives). I'm really impressed from its well optimized performance.

I'm setting "exec" and "system" to 0 (filling in P61_VBR myself) and using "CIA=1", as calling P61_Music myself during VERTB doesn't work very well with mods, which are setting the tempo (e.g. with "F7D").

Maybe you should consider to ignore an F-command with an argument >=32 (tempo), when CIA=0 ? Now the player sets $7D as speed, which is nonsense.

I would also like to use the "fade" option, but this means four expensive MULUs for scaling the volumes every time. How about a multiplication table for all 64 values (64*64 bytes) ?

Oh, come on A mul table takes 5 minutes to add!

I'm not the author of The Player 6.1, and the changes since its release have been very small bugfixes only, basically. I fixed two bugs and optimized the core.

I have intentionally left optimizing effects alone, since just using them already takes more time than you will optimize away from them. You could make them take almost nothing, but then you'd have to rewrite how the effects are done, and perhaps even change some period tables, period ranges, and make other commands.

In other words, in a "bad" spot in the song the musician might have used vibrato in 2 channels and volume fade in another at the same beat. That WILL cause a peak, and optimizing away half a scanlines for that bad moment wouldn't be sane. You couldn't do anything about it, except change the song, which is evil and murderous. Removing many scanlines from the core reduced everything including the peaks.

The F-speed has always been as you describe, since Soundtracker. You set the variable according to the tempo the musician had to choose. It's a compile option in P61, and it needs to be. Before that, you usually had to use one of two sources pre-coded for VBL or CIA, respectively.

P61 has always been about small module size and disabling chunks of code, which is why it has such a complicated set of parameters to set. Setting Usecode, for example, will set another bunch of conditional-compile options that you don't see among the normal ones. One of the biggest gains you will get is by simply setting the Usecode to what you see in the compressor utility, ie. never set it to -1!

Moving this to the Releases forum.

About the thread title: Note that I posted an even faster version P6108.lha after this, in spring 2010.

[phx]

Originally Posted by Photon

Oh, come on A mul table takes 5 minutes to add!

Sure. But I thought you might want to change that in the 'official' source.

In other words, in a "bad" spot in the song the musician might have used vibrato in 2 channels and volume fade in another at the same beat. That WILL cause a peak

Hm, ok. My game is prepared for that and will automatically skip frames, when running too slow. Probably there is even more danger for peaks coming from the game engine itself...

The F-speed has always been as you describe, since Soundtracker.

Really? That means you must use a CIA timer interrupt when the song contains Tempo commands. Ok, I can live with it.

Setting Usecode, for example, will set another bunch of conditional-compile options that you don't see among the normal ones. One of the biggest gains you will get is by simply setting the Usecode to what you see in the compressor utility, ie. never set it to -1!

I have more than a dozend songs in the game. I have the bad feeling that when I'm ORing all their Usecodes, I will automatically reach -1...

About the thread title: Note that I posted an even faster version P6108.lha after this, in spring 2010.

This is the version I'm using. Thanks.

[phx]

BTW, where is the source for P61Con? Is it available?
Would be useful to have P61Con as a portable command line tool, also for cross compiling.

[StingRay]

Originally Posted by phx

BTW, where is the source for P61Con? Is it available?

The source for the converter has never been made available to the public.

[Leffmann]

Originally Posted by phx

BTW, where is the source for P61Con? Is it available?
Would be useful to have P61Con as a portable command line tool, also for cross compiling.

Hey Frank,

I have the original P61 converter source.

The converter and GUI code are really woven into each other with next to no comments. I gave up on it after having done 3 different translations of the assembly sources and realizing the problem must be that I missed something when separating the converter from the GUI code.

I'll archive my sources and the originals and e-mail them to you.

Send me a PM with your e-mail if you want the sources too, Stingray.

[phx]

That's great, thanks!
Probably the source should be uploaded to Aminet, as the author wrote that it is public domain now.

And unfortunately you're right. Your conversion to C doesn't work for me either. But now it should be just a matter of time to get it running.