pouët.net

Go to bottom
LSP (Light Speed Player) by Oxygene [web]
screenshot added by leonard on 2021-03-10 22:56:07
platform :
type :
release date : march 2021
  • rulez 45
  • is ok 4
  • sucks 0
popularity : 62%
 62%
  • rulez 0.92
alltime top: #2466
added on the 2021-03-10 22:54:14 by leonard leonard

popularity helper

increase the popularity of this prod by spreading this URL:

or via: facebook twitter pinterest tumblr

comments

Fuck YES!!!!
rulez added on the 2021-03-10 22:56:42 by DanLemon DanLemon
Dropped this into my demo system last week, and it's working a treat!
added on the 2021-03-10 22:59:30 by DanLemon DanLemon
Easy to use, incredibly compact and fast. Yet another masterpiece from Leonard.
rulez added on the 2021-03-10 23:15:05 by Soundy Soundy
Excellent...
rulez added on the 2021-03-10 23:32:08 by Buckethead Buckethead
I need to try it. In the meanwhile, get my thumb up!
rulez added on the 2021-03-10 23:58:49 by ham ham
Well this sounds ace. Will get testing!
rulez added on the 2021-03-11 00:05:52 by Antiriad_UK Antiriad_UK
I particularly like the fact that there seems to be no obvious music replayer code in the code. Leonard can you explain wtf is going on here? :) :)
@Antiriad It's not playing a module "as such" ;)
added on the 2021-03-11 00:38:46 by DanLemon DanLemon
very cool! but could you please do a proper release package that could be e.g. archived on scene.org and traded on amiga telnet boards?
added on the 2021-03-11 00:48:11 by dipswitch dipswitch
@Antiriad all the magic is in the converter and the new data format. I'll write more technical details in the github readme soon.
added on the 2021-03-11 00:51:29 by leonard leonard
anyway, thumbs up of course
rulez added on the 2021-03-11 01:08:13 by dipswitch dipswitch
Excellent.

How applicable would that be to an STE? ;)
rulez added on the 2021-03-11 04:14:51 by keops keops
tool thumbs
rulez added on the 2021-03-11 04:39:43 by sensenstahl sensenstahl
An optimized mod compiler for Paula! Love the concept!
rulez added on the 2021-03-11 04:52:07 by Jobbo Jobbo
Haha 😛
An Atari ST veteran helps the Amiga community to push the envelope, report says.
´love that!
rulez added on the 2021-03-11 06:36:14 by fra fra
Demotools to the people!
rulez added on the 2021-03-11 08:45:53 by v3nom v3nom
Awesome. Thanks for making this "flat" stream player. Not long before ppl will ask for having sync markers in the stream so you can get your 8xx triggers back ;) I haven't tried it yet -- how does the stream size fare against the original pattern data (I know it will probably depend on the amount of notes and volume / pitch changes)?
rulez added on the 2021-03-11 09:09:03 by platon42 platon42
Wow, it's not even a raster line.
rulez added on the 2021-03-11 09:57:32 by Optimus Optimus
Excellent! Nice to see that finally some Atari-level optimizations take hold on the Amiga. I couldn't have used it vanilla in our last productions, but perhaps with some ringbuffer and/or Huffman decoding scheme.
rulez added on the 2021-03-11 11:13:23 by bifat bifat
Insane ;).
rulez added on the 2021-03-11 11:16:51 by sim sim
Impressive numbers in the screenshot at least 👍
rulez added on the 2021-03-11 11:18:11 by xeron xeron
Impressive numbers. Very cool release. To put it into perspective, do you think it would save enough cycles to do software mixing of two samples on 1 channel?
rulez added on the 2021-03-11 11:35:15 by alexh alexh
wow
rulez added on the 2021-03-11 11:36:22 by Frequent Frequent
awesome!
rulez added on the 2021-03-11 11:40:30 by wbc\\bz7 wbc\\bz7
Awesome speed and great idea!
rulez added on the 2021-03-11 11:41:28 by rloaderro rloaderro
well, that's one project I no longer need to look at coding.
rulez added on the 2021-03-11 11:44:45 by djh0ffman djh0ffman
Quote:
Awesome speed and great idea!

to be honest I'm a litle surprised that nobody used (or, rather, releasted to the public) this approach on amiga before (we're using register dumps on ZX for more than a decade, albeit compressed of course :)
added on the 2021-03-11 12:32:57 by wbc\\bz7 wbc\\bz7
Quote:
to be honest I'm a litle surprised that nobody used (or, rather, releasted to the public) this approach on amiga before (we're using register dumps on ZX for more than a decade, albeit compressed of course :)


register dump is a thing ( I did that 25 years ago with StSound and my .ym format ). But keeping the data size close to original .mod file, without using compression (because playing should be fastest as possible) was the fun part :) I tested several approach during development.
added on the 2021-03-11 12:51:16 by leonard leonard
Only Atari makes it possible :)
rulez added on the 2021-03-11 13:40:49 by Dascon Dascon
Quote:
Quote:
to be honest I'm a litle surprised that nobody used (or, rather, releasted to the public) this approach on amiga before (we're using register dumps on ZX for more than a decade, albeit compressed of course :)


register dump is a thing ( I did that 25 years ago with StSound and my .ym format ). But keeping the data size close to original .mod file, without using compression (because playing should be fastest as possible) was the fun part :) I tested several approach during development.


Cinter uses the same technique to be fair so it's not the first. The data size there is quite large but its simple enough for the compressor to turn it into next to nothing.
added on the 2021-03-11 13:47:05 by djh0ffman djh0ffman
Thumbs up!!! Looking forward to test it :)
rulez added on the 2021-03-11 16:33:50 by merry merry
Of course this rules.

Quote:
keeping the data size close to original .mod file, without using compression (because playing should be fastest as possible) was the fun part :) I tested several approach during development.
I am really looking forward to see what you did there. However, I'd like to flag that the suggested conflict between playback speed and the use of compression is to a large extent illusory; for a while now we have technologies on ZX Spectrum, for which _average_ playback speed of uncompressed PSG stream is slower than the average playback speed of the compressed PSG stream.
rulez added on the 2021-03-11 16:52:01 by introspec introspec
Impressive. Will try it for sure, thank you!
rulez added on the 2021-03-11 21:49:58 by sachy sachy
Great!
rulez added on the 2021-03-11 22:27:05 by p01 p01
But of course.
rulez added on the 2021-03-11 23:03:07 by spkr spkr
Excellent!
rulez added on the 2021-03-11 23:36:37 by Sdw Sdw
oh, sh*** .... been working on something very similar for a couple of years now, looks like you beat me to it :O

is the datastream compressed ?
rulez added on the 2021-03-12 11:57:06 by juice juice
Quote:
Not long before ppl will ask for having sync markers in the stream so you can get your 8xx triggers back ;)


While my player isn't nearly as slick or optimized as leonard's it does have this feature :) If you're curious and would like to test it feel free to PM me :)
added on the 2021-03-12 13:40:06 by juice juice
wrote a register-packed player like this back in '94 (1..2 scanlines) so this ain't exactly news to me. however: kudos for the package and overall presentation !
rulez added on the 2021-03-13 03:41:24 by bsp bsp
I've looked through the source now, and I have to say - the datastream format is quite brilliant. I never in a million years would've thought a scheme like the one used here would be comparable in size to the original pattern data without compression.

I've tested with a few chiptunes having a lot of volume and period changes and while the converted pattern data was sligtly larger than the original it wasn't nearly as much of an increase as I would've expected.

So this is the real achievement here - kudos!

I've found a flaw with the player which might make some tunes sound wrong, though. Rather than trying to explain, here's a test mod which illustrates the problem:

https://www.dropbox.com/s/w8obq2rp5sdd0cz/lsp-bug.mod?dl=0
added on the 2021-03-13 11:13:01 by juice juice
excellent
rulez added on the 2021-03-13 13:48:17 by skido skido
Super!
rulez added on the 2021-03-13 15:04:12 by bodo^rab bodo^rab
Quote:
I've looked through the source now, and I have to say - the datastream format is quite brilliant. I never in a million years would've thought a scheme like the one used here would be comparable in size to the original pattern data without compression.


thanks! I investigated several ideas before using this data format. I'm quite happy because it"s "almost" same size as original mod, and more important for me: it's really fast to decode

Quote:
I've found a flaw with the player which might make some tunes sound wrong, though.


thanks for the report! I'm already working on some fixes regarding mod duration detection (fail on some mods) and also some note triggering issue. I'll have a look at your mod. I'll release a v1.01 probably next week.
added on the 2021-03-13 16:40:13 by leonard leonard
Outstanding work, what a performance jump!
rulez added on the 2021-03-13 20:28:06 by ByteMavericks ByteMavericks
Thanks for keeping pushing the envelope, Leonard!
rulez added on the 2021-03-13 20:56:14 by exocet exocet
P61 version should be specified.
added on the 2021-03-13 23:03:11 by Photon Photon
Quote:
P61 version should be specified.


benchmark.adf is using "P6112-Play.i"
added on the 2021-03-13 23:52:51 by leonard leonard
Good.

If I were to make an optimal MODplayer, I would render the module using a standard player that has all the correct effect code to only a record of the changes to audio registers, resetting all if the song loops. Is this how it's done?

If so, this would mean that some code is not measured but must still be performed. If not, part of the playroutine is not measured.

The benchmark seems to use VBI tempo. P6112 can perform well for such modules. Were you able to set optimal mode/settings/usecode for P6112, so that it sets DMAoff without Copper instructions?

Just so you measure correctly. The screenshot is misleading.
added on the 2021-03-14 00:25:30 by Photon Photon
Quote:
The benchmark seems to use VBI tempo. P6112 can perform well for such modules. Were you able to set optimal mode/settings/usecode for P6112, so that it sets DMAoff without Copper instructions?


I'm not p61 expert I'm using baseline p6112. If you know how to finetune p6112 to get some cycles, please do a proper p6112 benchmark.

Quote:
Just so you measure correctly. The screenshot is misleading.


No, LSP benchmarks are measured 100% correctly. LSP insane mode is taking half a scanline on average, including everything.
added on the 2021-03-14 12:21:55 by leonard leonard
Quote:
I've found a flaw with the player which might make some tunes sound wrong, though. Rather than trying to explain, here's a test mod which illustrates the problem:


thanks for repro module. I fixed the issue. LSP v1.01 updated on github
added on the 2021-03-14 19:45:24 by leonard leonard
Quote:
thanks for repro module. I fixed the issue. LSP v1.01 updated on github


I see no significant change in the player code, I suppose you somehow fixed it in the converter? I suppose you could've cut off the beginning for short samples and immidiately go straight into the loop - is that what you did?
added on the 2021-03-15 11:23:42 by juice juice
Wahou, really impressive, and like fra said , thanks for this ;)
rulez added on the 2021-03-15 19:14:32 by TOUKO TOUKO
half a line !!! Now I'm waiting for a "Sprite world record" on amiga ;)
rulez added on the 2021-03-15 23:41:44 by Beb Beb
Quote:
half a line !!! Now I'm waiting for a "Sprite world record" on amiga ;)

NEVER provoke Leonard, you don't know what you're doing....
added on the 2021-03-16 00:31:28 by Soundy Soundy
Would it be possible for you to opensource the converter as well? I would love to port it to linux.
Fast as lightning. Massive thumb up for this tech
rulez added on the 2021-03-16 19:45:51 by Virgill Virgill
i dont have a clue but obviously this player is pretty dope!
rulez added on the 2021-03-16 20:00:52 by wysiwtf wysiwtf
awesome!
rulez added on the 2021-03-19 20:45:00 by Antony/DTA Antony/DTA
Inspiring! :) Bravo
rulez added on the 2021-03-22 13:43:44 by norecess norecess
yes
I got a question I was thinking about las days.
Using the LSP. As I understood one need to definitively change the music format from MOD to one used by LSP player by converting it.

Question: Would it be then possible to rip such a music file(s) from the production (i.e. disk, or memory) and write it back in a MOD musicformat? Or once converted, the MOD is "lost"?
added on the 2021-03-25 18:48:41 by sim sim
Quote:
Question: Would it be then possible to rip such a music file(s) from the production (i.e. disk, or memory) and write it back in a MOD musicformat? Or once converted, the MOD is "lost"?


In theory this is doable as LSP is a conservative format ( ie LSP or MOD should sound exactly the same ). But in practice it could be quite challenging to write the LSP to MOD converter ( you have to "guess" any mod fx to reproduce the exact stream of volumes and periods ).

Quite challenging, but doable. ( also keep in mind that such a reversed-mod will be totally obfuscated with plenty of weird fx commands )
added on the 2021-03-25 19:24:50 by leonard leonard
Wow! Very interresting!
rulez added on the 2021-03-26 17:14:00 by strife strife
Nice going and surprise! This could come in handy!
rulez added on the 2021-03-27 16:38:12 by magic magic
About time somebody did this! There is absolutely no reason that the complex decoding of ProTracker commands should happen at runtime.

The data format could be more compression friendly in various places (separation of streams by channel, selective delta coding etc.), but this would likely add a few cycles to the player. So for a pure focus on minimizing player time, this looks pretty optimal. For practical use in e.g. a 64k intro, I think a more compression friendly data format with a slightly slower player would be a better tradeoff in most cases.
rulez added on the 2021-03-31 12:27:28 by Blueberry Blueberry
First off, thumb up for walking the walk.

One thing I'd like to know, though. Can I read sync-relevant information such as current playlist-position or current pattern row from somewhere in the LSP code? Things like P61_Pos and P61_CRow for p61?
Is that retrievable from .LSPVars?
Thing is, we have a bunch of sync macros for the storyboard-routine in our framework depending on playlist position and pattern rows.

Thanks in advance
rulez added on the 2021-04-01 22:01:29 by d0DgE d0DgE
Quote:
So for a pure focus on minimizing player time, this looks pretty optimal. For practical use in e.g. a 64k intro, I think a more compression friendly data format with a slightly slower player would be a better tradeoff in most cases.


Thanks! You get exactly what I wanted for LSP "fastest" player: a reasonable .lsmusic file size but no compromise for speed.

And yes, making the player slightly slower there is tons of better format for compression. At first I wanted a single data format, to avoid having different files for the same music ( like a "speed" format and a "compressible" format).
But now I've worked on my 4KiB "SoftWired" compo, that is using LSP, I'lll definitively release a "-micro" option soon, with a different data format. Suitable for 4KiB. ( Anyway LSP is already used in two Oldskool 4KiB production this year :) )
added on the 2021-04-05 11:08:13 by leonard leonard
Quote:
First off, thumb up for walking the walk.


thanks :)

Quote:
One thing I'd like to know, though. Can I read sync-relevant information such as current playlist-position or current pattern row from somewhere in the LSP code? Things like P61_Pos and P61_CRow for p61?
Is that retrievable from .LSPVars?
Thing is, we have a bunch of sync macros for the storyboard-routine in our framework depending on playlist position and pattern rows.
Thanks in advance


Answer is "yes" and "no" :) This is definitively something I want to add, without getting speed compromise. I want to keep LSP as the low level music player. So right now what you could do is just keep your own "tick" counter (incremented per music player tick call). and just sync your effect using this counter.
I admit it's not very user friendly so I'm planning to add an LSPConvert option to also output a data file that give you the info between .mod sequence/row and LSP tick frame value
And I also plan for "few" event to support like .mod effect $E8x to export sync command in the stream ( and then you could poll this in LSPVars struct )
added on the 2021-04-05 11:13:44 by leonard leonard
Quote:
About time somebody did this! There is absolutely no reason that the complex decoding of ProTracker commands should happen at runtime.

The data format could be more compression friendly in various places (separation of streams by channel, selective delta coding etc.), but this would likely add a few cycles to the player. So for a pure focus on minimizing player time, this looks pretty optimal. For practical use in e.g. a 64k intro, I think a more compression friendly data format with a slightly slower player would be a better tradeoff in most cases.


A generic 'register replayer' with good pack ratio would be very useful. Something along 8 rasterlines.. I had to skip features for PreTracker because i already do 5x as much as a typical protracker replayer (and things get slow..)
If anyone can do it then Blueberry :)
added on the 2021-04-05 17:07:56 by Pink Pink
Quote:
I'm planning to add an LSPConvert option to also output a data file that give you the info between .mod sequence/row and LSP tick frame value


Please, do it. That would be very helpful.
added on the 2021-04-06 02:47:51 by ham ham

submit changes

if this prod is a fake, some info is false or the download link is broken,

do not post about it in the comments, it will get lost.

instead, click here !

[previous edits]

add a comment

Go to top