Light Speed Player

[ross]

To clarify: the conversion process generates a stream for Paula's registers, not a stream of samples.
Just like a generic module player would do (per tick) by processing the tracker commands.

[DanScott]

Originally Posted by Galahad/FLT

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

Would be interesting to see how many MB of sample data it creates

[ross]

Originally Posted by DanScott

Would be interesting to see how many MB of sample data it creates

It depends on the mixing frequency and the length of the song

[DanScott]

Originally Posted by ross

It depends on the mixing frequency and the length of the song

I'd go full 24bit 96khz just for the quality...

[Galahad/FLT]

Originally Posted by ross

To clarify: the conversion process generates a stream for Paula's registers, not a stream of samples.
Just like a generic module player would do (per tick) by processing the tracker commands.

Yes I know this, but don't see why the outputted LSP data would be significantly bigger.

Yes the data going to two of the channels is going to be denser having had two other channels mixed in, but there is also going to be 2 channels with ZERO data as a result, no data stream to process at all

[roondar]

Originally Posted by Galahad/FLT

Yes I know this, but don't see why the outputted LSP data would be significantly bigger.

Yes the data going to two of the channels is going to be denser having had two other channels mixed in, but there is also going to be 2 channels with ZERO data as a result, no data stream to process at all

Wouldn't the commands to set Paula to play up to 4 samples every now and then (I'm grossly simplifying here of course, I know it's more complicated than that) be much smaller than premixed audio for 2 channels?

Or am I misunderstanding what you want to do?

[Galahad/FLT]

Originally Posted by roondar

Wouldn't the commands to set Paula to play up to 4 samples every now and then (I'm grossly simplifying here of course, I know it's more complicated than that) be much smaller than premixed audio for 2 channels?

Or am I misunderstanding what you want to do?

The way I understand how the LSP conversion process works is it works as its own mod player, and at the point that the data is to pass to the audio hardware registers, its that data that is captured and saved as a stream.

That way it can correctly play/convert the mod in question and capture any tricks it does because it doesn't matter, at the point that the data is to be put into those hardware registers is what LSP captures.

My point is this, LSP can use fast mem for its entire music format, is incredibly fast to play.

If the 4 channels are mixed into 2 at conversion time, it will still be a fast replayer, the quality of the "mod" should still be good, and it frees up 2 channels.

My understanding of how Leonard does his conversion might be wrong of course, but that is what I'm presuming it does and if it does and Leonard feels up to it, the cpu intensive channel mixing gets done in the conversion process, leaving the 2 channel player still as fast as before.

[lmimmfn]

I think your suggestion Galahad would be brilliant if implemented

[Don_Adan]

Originally Posted by Galahad/FLT

Yes I know this, but don't see why the outputted LSP data would be significantly bigger.

Yes the data going to two of the channels is going to be denser having had two other channels mixed in, but there is also going to be 2 channels with ZERO data as a result, no data stream to process at all

From my memory about 20 mixed bytes is played by 1kHz in single VBI. Then for 28kHz you will be have:
28x20=560 bytes per 1 channel
2 channels is 1120 bytes per VBI
1 second is 50x1120= 56000 bytes per second.
For 60 seconds long song 3360000 bytes is necessary.

[no9]

Originally Posted by Galahad/FLT

My point is this, LSP can use fast mem for its entire music format, is incredibly fast to play.

Samples are still in chip.

[Jobbo]

Originally Posted by Galahad/FLT

The way I understand how the LSP conversion process works is it works as its own mod player, and at the point that the data is to pass to the audio hardware registers, its that data that is captured and saved as a stream.

That way it can correctly play/convert the mod in question and capture any tricks it does because it doesn't matter, at the point that the data is to be put into those hardware registers is what LSP captures.

My point is this, LSP can use fast mem for its entire music format, is incredibly fast to play.

If the 4 channels are mixed into 2 at conversion time, it will still be a fast replayer, the quality of the "mod" should still be good, and it frees up 2 channels.

My understanding of how Leonard does his conversion might be wrong of course, but that is what I'm presuming it does and if it does and Leonard feels up to it, the cpu intensive channel mixing gets done in the conversion process, leaving the 2 channel player still as fast as before.

I don't think it works that way at all. I think the stream it outputs is just driving Paula, directing it to DMA the correct sample data at the correct rate and volume.


All the samples still live in Chipmem. This is how I understand most MOD players work, the difference here is that it's no longer interpreting a MOD format in run-time to then drive Paula. It's partially compiling the MOD format data.

[Jobbo]

What might be possible for any MOD pre-processor would be to fold channels into each other to minimize sound clipping.

But I suspect only some really old or neive MODs with lots of empty space would benefit from anything like that.

[ross]

Originally Posted by Galahad/FLT

The way I understand how the LSP conversion process works is it works as its own mod player, and at the point that the data is to pass to the audio hardware registers, its that data that is captured and saved as a stream.

That way it can correctly play/convert the mod in question and capture any tricks it does because it doesn't matter, at the point that the data is to be put into those hardware registers is what LSP captures.

LSP conversion process captures pointer/length, period and volume, it knows nothing about samples.

My point is this, LSP can use fast mem for its entire music format, is incredibly fast to play.

Any module player could do this, it has nothing to do with the speed of LSP, which is due to not having to process the tracker commands in real time (which are preprocessed).

If the 4 channels are mixed into 2 at conversion time, it will still be a fast replayer, the quality of the "mod" should still be good, and it frees up 2 channels.

Pre-generating it would require an insane amount of chip memory.
You should do it for every channel mixing point (sample/pitch) you would encounter in the module (which is what real time mixers do).

[Galahad/FLT]

Originally Posted by ross

LSP conversion process captures pointer/length, period and volume, it knows nothing about samples.


Any module player could do this, it has nothing to do with the speed of LSP, which is due to not having to process the tracker commands in real time (which are preprocessed).


Pre-generating it would require an insane amount of chip memory.
You should do it for every channel mixing point (sample/pitch) you would encounter in the module (which is what real time mixers do).

Right ok, seems I misunderstood 100% how it worked

[a/b]

Originally Posted by ross

LSP conversion process captures pointer/length, period and volume, it knows nothing about samples.

Yeah, that's the basic idea. But it gets complicated when you introduce FX like sample offset, in which case you have to create virtual samples (you are not limited to PT's 31, it can go up to 5000+) that only reference parts of the actual samples.
So it can get rather complicated with the samples during the conversion, in order to make the player see no difference and don't do any extra work.

[ross]

Originally Posted by a/b

Yeah, that's the basic idea. But it gets complicated when you introduce FX like sample offset, in which case you have to create virtual samples (you are not limited to PT's 31, it can go up to 5000+) that only reference parts of the actual samples.
So it can get rather complicated with the samples during the conversion, in order to make the player see no difference and don't do any extra work.

[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...

LSP v1.03 is out! it fixes this corner case. Thanks a/b for the detailed description of the bug and the repro test .mod!

[a/b]

If you want to play several mods (generic player), there's a problem with m_relocDone because it's global and only the first mod will be relocated. Maybe instead check if the address of the first instrument is 4?

[leonard]

Originally Posted by a/b

If you want to play several mods (generic player), there's a problem with m_relocDone because it's global and only the first mod will be relocated. Maybe instead check if the address of the first instrument is 4?

correct. I'll add this to my next fix list

[ross]

I resume the talk about having a more compact format for .lsmusic

Although leonard, as you said, you must have done myriads of tests because the format is already very effective.
So it is more of an academic discussion that may or may not lead to something feasible.

The first thought was for a real time LZ(run) depacker, with a small circular buffer (perhaps in the stack) and short distance for matches (my tiny lz32b would be perfect for that).
But even if we solve the double stream problem, it still remains that it would be rather slow due to the fact that the extraction of the token would require a refill check every peeked byte.

But there is a different possibility, as we are not talking about random data but musical data.
Trackers usually work with vertical patterns, but the correlation even horizontally is often strong.
And it is the horizontal correlation that interests us because it represents the tick time in which you grab the notes and the effects.

So the question is: have you run any tests to see how often horizontal correlations are repeating?

Because adding a level of indirection and a dictionary (maybe even built with some entropy encoding) could save a lot of space.
Put simply: token -> dictionary -> stream_pair_pointers -> usual_decoding
Sure it would be slower, but not that much.