Super Optimized P6108.lha playroutine :)

[Photon]

I'm at Breakpoint 2010 and very happy Noname found me here and it was nice to talk to him

Here's the next version, anally optimized with non lev6 support and 1 bugfix, before aminet gets it

P6108.lha

Echo/Pan/Synth stuff prepared for next version Make something fun with the superexact Oscillator option!

Edit: Wow, the tag was longer than 25 chars so the posting failed.

Half an hour later I got this, and I wish someone could ftp this to aminet, as ftp is blocked here, it seems. Feel free to, the readme is in the archive. Or I'll do it when get back to Sweden.

[Photon]

I should also add that the web upload form to Aminet is still not working 1 month later. No pessimism, just fix it as soon as you can. Please! It would be great for parties where some ports are blocked!

[copperkid]

Hi, what kind of modules does this code support?
It's very basic information but seems to be missing in the .readme and at the top of P6108-Play.S.

Probably if you want to use this code it's assumed you know what you are doing but a little help for the newbie would be nice, thanks!

[Photon]

In short, it's a Protracker playroutine, but for the P61 format, which is Protracker modules packed with the P61con converter. So it supports The Player 6.1 modules, like the previous packages P6107.lha and P6106.lha on Aminet. So you take a Protracker module, crunch it with P61con, and use the playroutine in your program to play it (while displaying something very nice on the screen, of course!!)

[copperkid]

Cool thanks, I'll give it a try!

(of course while displaying some nice copper bars on the screen, at least )

[coze]

Originally Posted by Photon

(while displaying something very nice on the screen, of course!!)

so it doesn't work if displayed stuff isn't so nice

just kidding, great stuff ! will try as soon as possible !

[Photon]

OK, survived the trip back home (barely!) and uploaded to Aminet. I added an example of time gain to the readme for the archive.

>> Basically, this means a module that took 8.7 scanlines including
interrupts with V6.106 will now take 3.5 scanlines if nonLev6
and split4 is usable - circa 4.5 scanlines if split4 is not usable,
and if you don't want to use nonLev6 mode, add the time for the
DMAson and maybe the SetRepeat interrupt to that. About 140 cycles
for DMAson and circa 0.7 scanlines for the SetRepeat interrupt, for
4-channel modules.

I am supertired so good night

[Paradroid]

I thought I'd give this a go, but I'm having trouble getting it to play the first track from my Redux demo and was wondering if anyone else had found/solved the same issue.

Problems/Related Info:

* It seems at least one sample is playing incorrectly, like it is very short and looping rather than lasting at least a second and not looping.

* Playing the sample in isolation with no effects applied has no effect, it still does the fast looping behaviour.

* If I tinker with the module before conversion by stripping out some patterns it then starts playing fine. I guess doing this would change a whole host of things, so maybe not a good indication of what might be going wrong.

* It's not just my own mod going wrong, the next mod I tried (the second track from Anarchy's 3D Demo) had a very similar sounding issue.

* The same files play fine with P6104 and P6106. Note that I couldn't get P107 working at all, it was like it was playing the first row and then doing nothing else.

* I'm using the following settings and calling P61_Music once per frame
fade = 0
exec = 0
noshorts = 0
lev6 = 0
optjmp = 0
splitchans = 0
split4 = 0
playflag = 1
suppF01 = 0
dupedec = 0
oscillo = 0
quietstart = 0
clraudxdat = 0
use1Fx = 1
jump = 1
channels = 4
cia = 0
asmone = 0
system = 0
opt020 = 0

* Changing the lev6, quietstart and clraudxdat has no effect on the issue.



Considering how long it's been since this code was released I would have expected to find info about similar problems if it was a know bug, so I'm thinking it's more likely something I've done (although I've tried out the demo framework of a friend that was using p6108 and found the same problem, so it's not just me).

Any ideas before I go on a horrible debugging expedition?

[Photon]

P6106 isn't a doddle to get to run in the first place, with all those conditional compile flags especially with asmone=0. I continued that tradition with P6107 and 8, which doesn't make it easier, but if you can get the CIA example to play fine like the P6106 one, you should be able to just swap out the module in that.

I don't think you'll have to go on a debugging expedition. It has been tested with a bunch of modules that play correctly in PT2.3D, 3.11 and 3.15.

I can't really guess the real problem from your description. Please type the 4x channeldata for the first two notesteps here, or PM me and we'll have a look.

[Paradroid]

I can't see the mod right now (posting from phone), but I've got my test case down to the first pattern (of the redux demo track) being empty except for playing a single note and it goes wrong. I then reduce the pattern length of the entire mod and that single note plays fine. Instinct tells me memory corruption in my code, but then I get the same behaviour in a totally different code base and memory addresses. Bonkers :-P

I'll try a simplified setup using the CIA option tommorow and see how I get on.

[Paradroid]

hmm, no difference with CIA, same bugged sample. I'll zip up the tunes and PM you... And post what I've done wrong here once you've told me off :P

[Photon]

OK, so it works fine in P6107 but not in P6108.

What you call a looped sample in P6108 is that the first step is repeated perfectly at whatever Fxx speed you set. The same song works in P6108 if you make the song shorter in length.

The solution is to complete the fix I added to get rid of the "Bxx/Dxx in first pattern of 1-pattern song" bug. It fixed the bug and worked with a bunch of modules but got this side effect for certain modules or certain song lengths. I'll have a look as soon as I can.

It's not trivial to use these playroutines, especially as you discovered with certain assemblers that have automatic optimization of jumps to branches that messes things up. If you have a directive to turn off optimization for assembling the playroutine, I recommend you use it. It's already optimized.

Also, some raster optimization flags added by me are incompatible with certain features, so have a look at my notes regarding this if you use them.

It's not trivial to use P6108 either, to get the last 2 scanlines or so gain you must call it in your mainloop or vblank and put some copper moves to audio regs 4 scanlines lower than when P61_Music finishes and point the playroutine to it.

If you don't want to do that, you can't get the raster gain, so P6107 is exactly as good then.

If you run P610x with usecode -1 you can assemble a plug-in binary, but of course then you gain much less rastertime. Usecode -1 is still compatible with P6108's splitchans, which knocks down max rastertime noticably. But again, in general I have no problems using P6108. I convert the module, set the usecode and optimization options, and it works right away.

But head-scratchers are unavoidable when you start with a big, complex playroutine with lots of legacy code. My 1Klång format takes it away from this direction with a PT converter made to simplify what musicians want to do with the instruments instead of robotic compression of clumps of effect codes. This makes the playroutine tiny and clean, and gives support for some new nice things you can do with the synth or sample instruments.

[losso]

I might have run into the same (?) issue: A note is sometimes triggered with a delay or distorted. Also, similar to Paradroid's observation:

* Changing the lev6, quietstart, clraudxdat and CIA options had no effect on the issue

* If I tinker with the module before conversion by stripping out some patterns it then starts playing fine

* The same file plays fine with P6107

If it is of any help, I've attached the module showing the described behavior. At 0:22, right after the Giana Sisters power-up sound, you should hear "dah" or something similar right afterwards. Using P6108 playback, that "dah" is delayed for about a second. Maybe related to the D00 pattern break I use in every pattern at row 47?

For now, using P6107 is perfectly fine for me, though!

[Photon]

Originally Posted by losso

Maybe related to the D00 pattern break I use in every pattern at row 47?

Yes.

My spare time has been booked solid since end of June, but I may have time to look at this soon. Maybe wishful thinking, but...

[losso]

Heh, no worries

I'm mostly glad it's not a subtle bug on my side, this time. Thanks for looking into it!

[Photon]

Yes, the samples look strange when I load it in Protracker. It seems to not get the names of the samples, and can't read them properly from the module. Sample 11 is 15K long, but only has 1K of sound in it, sample 12 is 16K with only 50 or so samples in it, and sample 13 is 3K of silence.

It seems only the speech synth samples are mangled and the others are OK. Maybe they were imported incorrectly?

To use the P61 converter, your module must use a Protracker format released before the converter was released in 1998, else it's not certain that it can be converted at all.

A rough check is to play it in a module player or tracker version that is that old. I use PT 3.15 and take a quick look at the notedata and listen as it plays. If you/I haven't heard the module before, then it's not always possible to hear if it plays correctly. So it's best if the musician does this pre-check.