| LSP (Light Speed Player) by Oxygene [web] | ||||||||
|---|---|---|---|---|---|---|---|---|
|
|
|||||||
|
popularity : 66% |
|||||||
alltime top: #2090 |
|
|||||||
|
||||||||
added on the 2021-03-10 22:54:14 by leonard  |
||||||||
popularity helper
comments
Fuck YES!!!!
rulez added on the 2021-03-10 22:56:42 by DanLemon 
Dropped this into my demo system last week, and it's working a treat!
Easy to use, incredibly compact and fast. Yet another masterpiece from Leonard.
Excellent...
I need to try it. In the meanwhile, get my thumb up!
Well this sounds ace. Will get testing!
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" ;)
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?
@Antiriad all the magic is in the converter and the new data format. I'll write more technical details in the github readme soon.
anyway, thumbs up of course
Excellent.
How applicable would that be to an STE? ;)
How applicable would that be to an STE? ;)
tool thumbs
An optimized mod compiler for Paula! Love the concept!
Haha 😛
An Atari ST veteran helps the Amiga community to push the envelope, report says.
´love that!
An Atari ST veteran helps the Amiga community to push the envelope, report says.
´love that!
Demotools to the people!
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)?
Wow, it's not even a raster line.
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.
Insane ;).
Impressive numbers in the screenshot at least 👍
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?
wow
awesome!
Awesome speed and great idea!
well, that's one project I no longer need to look at coding.
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 :)
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.
Only Atari makes it possible :)
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.
Thumbs up!!! Looking forward to test it :)
Of course this rules.
Quote:
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.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.
Impressive. Will try it for sure, thank you!
Great!
But of course.
Excellent!
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 ?
is the datastream compressed ?
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 :)
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 !
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
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
excellent
Super!
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.
Outstanding work, what a performance jump!
Thanks for keeping pushing the envelope, Leonard!
P61 version should be specified.
Quote:
P61 version should be specified.
benchmark.adf is using "P6112-Play.i"
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.
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.
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.
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
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?
Wahou, really impressive, and like fra said , thanks for this ;)
half a line !!! Now I'm waiting for a "Sprite world record" on amiga ;)
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....
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
i dont have a clue but obviously this player is pretty dope!
awesome!
Inspiring! :) Bravo
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"?
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"?
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 )
Wow! Very interresting!
Nice going and surprise! This could come in handy!
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.
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.
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
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
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 :) )
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 )
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 :)
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.
like for source!
Nice work. Is there any point to bring LSP players to other systems (e.g. Atari) in the future? Or is a lot of the speed in the player obtained through tight coupling to Amiga Sound hardware architecture?
Quote:
Please, do it. That would be very helpful.
LSP v1.10 is out. New optional timing features:
LSP_MusicSetPos : to set position to any sequence pos
LSP_MusicGetPos: To get the current seuence pos
Enjoy!
https://github.com/arnaud-carre/LSPlayer
Top notch customer service ;)
Quote:
LSP_MusicSetPos : to set position to any sequence pos
great, this was the missing piece for me. Thanks for releasing updates!
Quote:
Top notch customer service ;)
Music replayers seem to be a hot topic, but I have to confess I do not
have the foggiest when you (crazy) pals start talking shop.
Nevertheless it is fun to read and I had to chuckle about what Soundy
wrote..."NEVER provoke Leonard, you don't know what you're doing...."
Half a rasterlime - that is insane. Wonder what the next generation will
look like (will it generate & provide you with free cycles?....just kidding
:-) )
have the foggiest when you (crazy) pals start talking shop.
Nevertheless it is fun to read and I had to chuckle about what Soundy
wrote..."NEVER provoke Leonard, you don't know what you're doing...."
Half a rasterlime - that is insane. Wonder what the next generation will
look like (will it generate & provide you with free cycles?....just kidding
:-) )
Just added a "-micro" mode to get high compression ratio on the .lsmusic file. Perfectly suited for 4KiB or tiny intros! AmigakLang is the best friend of LSP "-micro" mode :)
https://github.com/arnaud-carre/LSPlayer
https://github.com/arnaud-carre/LSPlayer
Thx for the update leo! That comes in handy <3
thanks again, Leonard. I used this in our latest intro. No problems encountered. Worked perfectly.
LDOS and LSP are game changers!
some news about LSP: now it comes with full LSP converter source code! Enjoy!
Really useful tool!
lists containing this prod
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 !