Light Speed Player

[Jobbo]

This new replay routine by Leonard sounds utterly bonkers!


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


I don't know very much about how player routines normally work. It was always a black box I never wanted to look in.


But now I would be really interested to hear how those routines worked and how this one is able to smash the old records!


Amazing stuff!

[lesta_smsc]

Incredible! I mean the speed is insane and command line is really simple to convert the files. Given its ridiculously small file size, this could easily be incorporated into future productions saving quite a bit of space for other interesting things

[DanScott]

Traditional MOD player code is reading the song data, calculating all the stuff and then writing the data to the audio hardware registers

What LSP does, is cut out the middle man, and converts the mod into literally a stream of data that can be read and written quickly to the hardware registers.

This is why the regular LSP player is less than 512 bytes, but the converted module *could* be larger (but not always) than the original module.

[a/b]

Comparison to P61 is not really fair: any optimized PT player using a custom format should be noticably faster due to P61's real-time pattern decompression (and there's still plenty of optimizations to be made in P61).
Interesting approach, and really good work nonetheless.

[DanScott]

Originally Posted by a/b

Comparison to P61 is not really fair

Yes it is... essentially they are both doing the same thing.. playing a module

[a/b]

Originally Posted by DanScott

Yes it is... essentially they are both doing the same thing.. playing a module

So does a bus and "my Ferrari"... transport passengers ;P. Or maybe a more relevant example, demo vs. wild demo (but in this case you could just say TBL and it becomes irrelevant :P :P ).
They don't provide the same functionality:
P61 = play + compress
LSP = play
For some people, not specifically you, it's just semantics, maybe they don't really care much about the compression, it's a bonus. As long as it's reasonable simple to use and fast (read: doesn't get nuked to 15-16 rasterlines range if you happen to use fine-tuning).
I wouldn't touch P61 if it wasn't for the compression (if your audio budget is say 192kb, getting ~30kb more for the samples is really nice), especially after seeing the source code. Have to feel sorry for all the poor guys who volunteered to maintain it :P.
So yeah, from my perspective they are not in the same category.

[leonard]

Originally Posted by a/b

So yeah, from my perspective they are not in the same category.

I disagree. LSP is a module player, data takes "almost" the same size of a original MOD ( sometimes smaller, sometimes bigger ). It's true P61 almost produce smaller files, but LSP is not far from .mod regarding file size. And don't forget the added size is "any memory". It doesn't waste audio chip memory ( so it's generally not an issue for a demo to add some "any memory" data.

LSP idea is very simple: dump PAULA registers. But data format to decode insanely fast AND keep a reasonable data size as .mod does IS the key feature.

[lmimmfn]

Does anyone have qny CPU usage comparisons of rhis technique vs regular mod player? Or DMA access info(presumably will be the same)

[Galahad/FLT]

Originally Posted by lmimmfn

Does anyone have qny CPU usage comparisons of rhis technique vs regular mod player? Or DMA access info(presumably will be the same)

The whole point of LSP is to reduce cpu time. LSP is primarily going to be used by those coding intros and demos that need to squeeze every last piece of performance from the machine.

LSP has done away with all the calculations in the conversion phase, I cant imagine this method takes up very many raster lines at all.

[leonard]

Originally Posted by lmimmfn

Does anyone have qny CPU usage comparisons of rhis technique vs regular mod player? Or DMA access info(presumably will be the same)

you can run "benchmark.adf" in the LSP archive. Basically LSP normal mode is 1 raster line average time (with 2 rasterlines peak )
LSP Insane mode is half a raster line average time, and 1 raster line peak

[roondar]

I'm still amazed at just how fast it is. Worst case of only 0,6% CPU use per frame
Truly a great achievement.

[a/b]

Originally Posted by leonard

I disagree. LSP is a module player, data takes "almost" the same size of a original MOD ( sometimes smaller, sometimes bigger ). It's true P61 almost produce smaller files, but LSP is not far from .mod regarding file size. ....

Not sure what you are disagreeing with. I'm not critisizing LSP, it's very good for what it does. Again, P61 will inherently be slower than any similarly optimized PT player due to real-time decompressing, and this is by design. That's why I'm saying it's unfair (and I don't mean 100% unfair, it's always a grey zone, depends who you are asking): LSP is a mod player, P61 is a mod player and compressor.

About the size (the "almost" part in your post)...
P61 typically reduces patterns size down to about 1/4-1/3. One of my test modules has 41 patterns (real music, not a bunch of empty notes), and that's compressed to 7.5kb (header+patterns), for example. ~34kb memory saved, or extra ~34kb for the samples, potentially resulting in better music.

As I said, some people don't care about that (does it work? check), or memory is simply not an issue. But in same cases it is, for example occasionally you can read here how game devs are talking about memory constraints and how to fit everything within 0.5mb or 0.5+0.5mb, all while using a PT player that can spike up to 16 rasterlines.
Use whatever works best in your scenario.

[DanScott]

Isn't P61 incompatible too with some Protracker commands (I seem to remember a list of the unsupported stuff)

LSP supports all commands, so can play back modules 100% where P61 can't

P61 also alters the samples, so an external tool (for example aklang), that relies on samples being in the locations that a module specifies, won't work correctly with P61 either

[no9]

So now you describe that they are not doing the same thing?

[8bitbubsy]

I have mixed feelings about LSP. It's good for what it is, but calling it the "fastest .MOD player" is a bit misleading, in my opinion. In the end, it has nothing to do with the old format.

[roondar]

The interesting thing about methods like LSP uses is that it should actually be format-independent. As long as a converter can be made, LSP should be able to play it. In that sense, it's not a .MOD player.

But in the sense of how it's been presented now (with AFAIK only a .MOD converter), I have no real issue calling it a .MOD player as that is what it's used for (albeit with a conversion ahead of playback).

[DanScott]

Originally Posted by roondar

But in the sense of how it's been presented now (with AFAIK only a .MOD converter), I have no real issue calling it a .MOD player as that is what it's used for (albeit with a conversion ahead of playback).

The same is true of p61 too

[roondar]

Exactly! I'd call P61 a .MOD player as well

[no9]

So P61 is kind of lossy compression for mods.

[a/b]

P61 doesn't suport pattern break Dxx if xx != 0 (performance hit because of compression), E4x/E7x rect/saw vibrato table (not because it can't), E3x glissando (don't know the reason). LSP doesn't support short samples (have to pad manually), EFx funk (can't work), some mods can explode in size.
In practical terms, other than size explosion (change tool) these are all nothingburgers for me personally.

Roondar brings up an interesting point, LSP could easily be format independent. Just need to write a converter.

Originally Posted by no9

So P61 is kind of lossy compression for mods.

Samples, yeah (it's optional). I handle those things outside, with a dedicated compressor. Same for sample delta/undelta since not only samples benefit from it.