A new really fast MOD replayer

[leonard]

Hi!

Another Amiga MOD replayer! Key feature of this one is .. speed Average speed per frame is 6 times faster than previous fastest amiga player. Hope you'll appreciate!

https://www.pouet.net/prod.php?which=88177

[Antiriad_UK]

Yay. Can’t wait to try out. Just commented on pouet - how does it work as replayer code looks nothing like replay code would love an insight.

[Jobbo]

Sounds incredible!

Could you possibly write up some details on how players normally work and how you managed such an amazing improvement?

I would be fascinated to hear the details!

Thanks regardless! Awesome contribution!

[Antiriad_UK]

Originally Posted by leonard

Hi!

Another Amiga MOD replayer! Key feature of this one is .. speed Average speed per frame is 6 times faster than previous fastest amiga player. Hope you'll appreciate!

https://www.pouet.net/prod.php?which=88177

Btw. You should have skipped light speed and gone full spaceballs ludicrous speed

[ Show youtube player ]

[leonard]

basically all magic is in the converter and the new data format. The converter is really processing the music file (all mod fx are supported), and basically output a stream of direct amiga hardware register values. To keep the final data size reasonable I tested tons of various data encoding and I'm happy with the final result. LSP files are "almost" same size as original .mod file ( sometimes smaller, sometimes bigger, depends of the .mod)
The "insane" mode is a generated source code using a dedicated piece of code for every combine of hardware registers to set per frame. Obviously all combine won't fit, so only patterns used in the specific .mod are generated.
I wrote LSP when I was writing some Amiga world records and I was annoyed by the "peak" time of all other player. Like if you want to beat a sinus-dots demo, every cycle count

[Jobbo]

Thanks Leonard!

When can we see these record breaking effects? Revision???!!

[lesta_smsc]

Already posted on another topic for the same player, but well done @leonard on this. I wonder how this will change things for the future of demo scene where every byte counts! I know there are some demo competitions for very small files on pouet so this could be a game changer - is there scope to use this on PC for say .xm type files?

[Antiriad_UK]

So sounds similar to the really old school spectrum 128 files where it’s a stream of output.

Current intro I’m working on is deep into note triggers and/or e8 triggeres. Can I message you about those?

[a/b]

Took a quick look at the standard player. One question: are there any restrictions regarding the minimum sample size? It looks like you are using the same method to set the repeats as P61 in noshortsamples mode (postponed until the next frame, instead of after ~11 raster lines).

[roondar]

This is really cool, I'll be checking it out for sure!
Great stuff, the code seems easy to integrate as well

[leonard]

Originally Posted by Jobbo

Thanks Leonard!

When can we see these record breaking effects? Revision???!!

That was the plan, but unfortunately my gfx artist was too busy and I didn't get any gfx in time for Revision That's why I release LSP as a standalone (LSP was sleeping on my disk for too long )

I still have some features I want to add for next version:

- ability to "sync" music with demo effects, without losing any cycle if you don't need to sync ( probably generating a table with frame number <-> mod position. Then it's up to the user to sync using the frame count number

- LSPConverter already "simulate" the complete mod and warn you if some samples are not played completely. Right now it's just a warn, but I can just strip the end of the sample ( I think no amiga tool is doing that right now )

[ross]

Great stuff Leonard!

Originally Posted by leonard

- LSPConverter already "simulate" the complete mod and warn you if some samples are not played completely. Right now it's just a warn, but I can just strip the end of the sample ( I think no amiga tool is doing that right now )

Perhaps you can do the opposite as well ('enlarge' the sample) in the case indicated by a/b a couple of messages above.

[Samurai_Crow]

@leonard
Would using the Copper as a feeder to the registers behind the visible portion of the display be a plausible upgrade path? It would allow the CPU portion of the player to mesh with the "copper node" sorting and interleaving so that multiple calls for when the tempo would have required multiple CIA interrupts to be replaced by a callback hook in the copper list generation. A fortunate side effect of counting timing by rows of rasters at 15KHz would work equally well on PAL and NTSC modes. Having to wrap around the vertical blank with copper activity would seem to be the only side effect, other than the music nodes being stored in Chip RAM.

[leonard]

Originally Posted by ross

Great stuff Leonard!


Perhaps you can do the opposite as well ('enlarge' the sample) in the case indicated by a/b a couple of messages above.

that's is definitively a good idea: doesn't slow down the replayer at all. I never found an audio issue with really short sample. Do you know any .mod file that have this "frame delay to set replen" issue I can test?

[robinsonb5]

Originally Posted by leonard

- LSPConverter already "simulate" the complete mod and warn you if some samples are not played completely. Right now it's just a warn, but I can just strip the end of the sample ( I think no amiga tool is doing that right now )

That's really cool! If you do strip away the unused data, though, be sure to take care of PAL/NTSC base clock differences, and maybe leave a few bytes' headroom for the benefit of non-cycle-exact emulation?


I'd also like to say thank you for sharing the source of your tiny LZ4 depacker.

[alexh]

Very cool. I wonder... does it save anywhere near enough cycles to software mix two channels into one? Leaving 1 channel free for SFX?

[chiark]

Brilliant, especially to keep size down too. Could this be the basis of a new format for Amiga audio...? (Realise it's basically a format that's setting hardware registers, but all the same it could be the right thing at the right time on that front too!)

[ross]

Originally Posted by leonard

Do you know any .mod file that have this "frame delay to set replen" issue I can test?

Sorry no, right now no specific .mod comes to mind.
I can only assume that some peculiar 'chip' type modules are more likely to suffer from this.

[saimo]

Congratulations and thanks!

[pink^abyss]

Originally Posted by leonard

basically all magic is in the converter and the new data format. The converter is really processing the music file (all mod fx are supported), and basically output a stream of direct amiga hardware register values. To keep the final data size reasonable I tested tons of various data encoding and I'm happy with the final result. LSP files are "almost" same size as original .mod file ( sometimes smaller, sometimes bigger, depends of the .mod)
The "insane" mode is a generated source code using a dedicated piece of code for every combine of hardware registers to set per frame. Obviously all combine won't fit, so only patterns used in the specific .mod are generated.
I wrote LSP when I was writing some Amiga world records and I was annoyed by the "peak" time of all other player. Like if you want to beat a sinus-dots demo, every cycle count

Great execution Leonard! As always, you win over any amiga coder in optimization

Inspired by LFT from C64 I tried the same a year ago with my Pretracker replayer but my data exploded. A 3 minute song took around 50kb of replayer data when the original song only had 7kb of pattern data, so i scrapped it