Light Speed Player

[ross]

Originally Posted by a/b

LSP doesn't support short samples (have to pad manually).

Perhaps this is fixed in v.1.01:

v1.01
	- fixed mod ending detection issue
	- fixed very short samples issue
	- fixed one frame delay when music loop in "insane" mode
	- fixed bad player init if called two times in normal player
	- added "-renderwav" option to debug any .mod parsing error

EFx funk (can't work)

This command, like all those that modify the samples (E8x?), are very slow in any player, so they could be included conditionally (disabled by default, code as is) and whoever activates it is aware of slowing down the play

some mods can explode in size.

This could be solved using some form of real time depack for the streamed data.
Not that it's simple and / or quick to (de)code..

[leonard]

Originally Posted by a/b

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.

I was speaking about not comparing p61 and LSP. To me, p61, ptplayer, LSP or any mod player could be compared. Playing an MP3 can't be compared. I think the comparison is fair if they all play a module, use almost same quantity of data as original .mod file. ( that's why mp3 or just wav would be unfair ).

Btw p61 compression doesn't mean it slow down. p61 is faster than any previous protracker players, despite it use compression.

In a way, LSP also use compression. If you store PAULA registers stream "as it is", the music size would explode for sure

that's why I think think it's fair to compare LSP with any other amiga MOD player. (but that's not an important point )

[leonard]

Originally Posted by a/b

LSP doesn't support short samples (have to pad manually)

you're right. Main reason is amiga player optimization, setting replen in the next frame. I'm not happy with that. I did a fix to automatically extend micro-samples if needed (v1.01) but I'm still not 100% happy (there is some situation that aren't properly fixed).

I already added a wav exporter user can check if .mod parsing is ok. But now I'm adding a real paula emulation & LSP player code so you could also generate a wav that will be the same output as LSP running on Amiga ( with the same sound issues due to replen etc..). I think it's a great feature for musician that could check if the music will sound ok on amiga without needing one

[leonard]

Originally Posted by 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.

Exactly! it's a bit like my atari .ym format that could theorically be played on any hardware using a ym2149 chipset.

Originally Posted by roondar

In that sense, it's not a .MOD player.

To be exact I would say "it's not only a .MOD player"

[Antiriad_UK]

Originally Posted by leonard

Exactly! it's a bit like my atari .ym format that could theorically be played on any hardware using a ym2149 chipset.

I did a Vectrex mod for a friend a while ago and that was in YM format (Arkostracker composed) and coming from the Amiga side I was like "Soo....it's not really a "mod" it's just a stream of sound chip data?!". Blew my mind

Don't let any comments on here bother you. Everyone just likes arguing over new things - You are doing a massive service to the community!

[a/b]

Originally Posted by ross

This command, like all those that modify the samples (E8x?), are very slow in any player, so they could be included conditionally (disabled by default, code as is) and whoever activates it is aware of slowing down the play

I'd just be practical and don't bother. It's not really in the spirit of LSP's fast replay IMO. Just use the most compatible player if you really need that (who does in a demo/intro).
I was just responding to "can/can't play 100%" ;P.

Originally Posted by leonard

you're right. Main reason is amiga player optimization, setting replen in the next frame. I'm not happy with that. I did a fix to automatically extend micro-samples if needed (v1.01) but I'm still not 100% happy (there is some situation that aren't properly fixed).

[roondar]

Originally Posted by leonard

To be exact I would say "it's not only a .MOD player"

That's just as valid as what I wrote, so yes

[8bitbubsy]

EFx (invert loop) has been used quite a bit in music in cracktros, at least. And why is it slow? It has no inner loop, it just inverts one chipmem sample byte per tick.
E8x (karplus-strong) on the other hand, has an inner loop and can be considered "slow". I have yet to see this effect being used in a PT .MOD though, other than fx sync...

[ross]

Originally Posted by 8bitbubsy

EFx (invert loop) has been used quite a bit in music in cracktros, at least. And why is it slow? It has no inner loop, it just inverts one chipmem sample byte per tick.

Yep, true .
But on LSP there is no such concept as "command".
So you should make an exception and define an 'escape code' that allows you to execute generic code, which in this case modifies the sample in chip memory.
Sure feasible, but that's what would make it slower (and I don't know how it might impact the stream).

-
Changing the subject, I was thinking of a possible encoding for compression, but the double stream makes things difficult..

[DanScott]

At the end of the day, the coder will choose their weapon of choice (player) based on their needs... and then it is up to him/her to let the musician know which commands are or are not supported.

[a/b]

Originally Posted by ross

Changing the subject, I was thinking of a possible encoding for compression, but the double stream makes things difficult..

I tried a single 16-bit stream (codes, volumes, instruments, periods are all 16-bit, also it's not super optimized so maybe it could be made a little shorter), taking a step back hoping it would be easier to take two steps forward, but I don't think it's the way to go. I get around 50% larger patterns size, doubt any compression would be able to compensate. Codes takes a larger portion of extra size.
Going full 8-bit would impact the run-time performance :\.

[leonard]

Originally Posted by a/b

I tried a single 16-bit stream (codes, volumes, instruments, periods are all 16-bit, also it's not super optimized so maybe it could be made a little shorter), taking a step back hoping it would be easier to take two steps forward, but I don't think it's the way to go. I get around 50% larger patterns size, doubt any compression would be able to compensate. Codes takes a larger portion of extra size.
Going full 8-bit would impact the run-time performance :\.

LSP was designed to get world record speed (and keep LSP file a reasonable size, ie approx .mod size). You can easily make .lsmusic file a bit shorter if you use 8bits for instruments ( instead of 16 currently. Also you could have a period table and put the most used in 256 first entries and use escape code for others. You may loss maybe half a raster line doing that.

That wasn't my goal

And again, precious memory in a demo is "chip" memory for samples. LSP streams are in "any" memory, that's not so important. ( people used .mod for years without complaining about compression )

[a/b]

Yeah, I get that. When I said not super optimized in size I was talking about my quick "hack" (basically I was screwing around for a few hours, took the PT2.3F source and modified it to output a stream using the same 16-bit codes schema as LSP, except everything is 16-bit because it's just a quick proof of concept and made for experimentation).
It's easier for me to better understand how/why stuff works after actually implementing it, facing the problems and thinking how to solve them.
As in this particular case, how to potentially compress/pack stuff to reduce size, since Ross kind of started a discussion about it, and it's something I'm interested in because at this level of speed 1 or 2 rasterlines is not that big of a difference if it comes with additional benefits (like noticably smaller size).

[leonard]

LSP v1.02 is out

v1.02
- fixed bug in $9xx fx (sample offset)
- added "-amigapreview" : generate a wav from LSP data (output simulated LSP Amiga player)
- added "-nosettempo" to remove $Fxx>$20 settempo support (for old mods compatibility)

-amigapreview is quite nice option: musician can listen to the LSP as it was played by Amiga LSP Player ( with Paula SetRepLen next frame simulation etc)

[a/b]

While thinking about bullet-proof exit/special codes $F00F, I did a few tests and found a bug with resetv vectors. It's a rare case, but you never know...
How to reproduce:
- speed is 1 (F01), meaning repeats could be cancelled if a new note is played on the same channel immediatelly after
- row1: play a note on all 4 channels, chn1-3 sample A, chn4 sample B
=> code is $0FFF, resetv are set as: B A A A (4->1)
- row2: play a note on channels 1/2/4, all sample A
=> code is $4BBB
Now the player will set a repeat for channel 3 (1/2/4 are playing a new note and are skipped), but it will use the first resetv from the previous row, sample B, which was used by channel 4.
Also, I'm using Cxx effects and the bits for volume are also set, but that doesn't matter here (I was trying to reproduce invalid $FFFF).

Tested with v1.02. I've attached a mod in case it's not entirely clear. It's just some 'noise' :P but the difference can be heard.

[leonard]

Originally Posted by a/b

While thinking about bullet-proof exit/special codes $F00F, I did a few tests and found a bug with resetv vectors. It's a rare case, but you never know...

oh very good catch! the fix is easy and won't lose too many cycles ( probably around 20cycles). I'll do a fix tonight.

thanks for bug report!

[8bitbubsy]

Originally Posted by leonard

[...]
- added "-nosettempo" to remove $Fxx>$20 settempo support (for old mods compatibility)
[...]

If this is trying to simulate vblank playback, you need to allow the whole Fxx range for setting ticks per row, IIRC.

[Galahad/FLT]

Originally Posted by leonard

oh very good catch! the fix is easy and won't lose too many cycles ( probably around 20cycles). I'll do a fix tonight.

thanks for bug report!

This is great stuff, can I suggest a new mode you might consider adding?

A channel conversion mode where 4 channels are mixed into two, so when playback is done, we still have what appears to be a 4 channel mod, but only playing on 2 channels which is going to be great for mixing in VFX for games?

[DanScott]

Originally Posted by Galahad/FLT

This is great stuff, can I suggest a new mode you might consider adding?

A channel conversion mode where 4 channels are mixed into two, so when playback is done, we still have what appears to be a 4 channel mod, but only playing on 2 channels which is going to be great for mixing in VFX for games?

That would require realtime sample mixing

[Galahad/FLT]

Originally Posted by DanScott

That would require realtime sample mixing

Er only in the conversion process which can be as slow as it likes.