Protracker player with support for external sound fx

[zedr]

First of all, thanks for sharing your player.

I am trying to use it as-is in my C program and I run into this error during compilation.

vasmm68k_mot -m68000 -noesc -Fhunk /data/ptplayer.asm -o asm.o
vasm 1.8 (c) in 2002-2017 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.2 (c) 2002-2017 Frank Wille
vasm motorola syntax module 3.10 (c) 2002-2017 Frank Wille
vasm hunk format output module 2.9a (c) 2002-2017 Frank Wille

CODE(acrx2):	       13096 bytes
vc +kick13 -c99 -cpu=68000 -I/root/amiga_sdk/NDK_3.9/Include/include_h -lamiga -lauto -g -c /data/animtools.c
vc +kick13 -c99 -cpu=68000 -I/root/amiga_sdk/NDK_3.9/Include/include_h -lamiga -lauto -g -c /data/main.c
vc +kick13 -c99 -cpu=68000 -I/root/amiga_sdk/NDK_3.9/Include/include_h -lamiga -lauto -g -c /data/msx.c

error 9 in line 13 of "/tmp/fileJt6Y2C.asm": instruction not supported on selected architecture
>	movec	vbr,d0
vasmm68k_mot -quiet -Fhunk -phxass -nowarn=62 "/tmp/fileJt6Y2C.asm" -o "/data/msx.o" failed

Any idea on what I'm doing wrong? Thanks!

[phx]

Not sure what you did there. In the first line you showed that assembling ptplayer.asm definitely works. Then later you compile a C source and it fails? There is also no MOVEC in ptplayer.asm.

As I understand it, you inserted a MOVEC assembler-inline into msx.c to read the VBR, but you insist in compiling for cpu=68000? Then the error is correct, because MOVEC is an 68010 instruction.

[jotd]

looks like generated startup file isn't compatible with 68000... nothing to do with ptplayer I confirm. You need to provide VBR to the player but player doesn't read it itself (would require supervisor calls).

Compile your c source with 68010 mode, and call MOVEC only if current CPU is 68010 else return 0.

I don't think you risk introducing incompatibilities with 68000 with 68010 mode, unlike 68020 mode which could "optimize" with odd-address word read.

[Photon]

To be compatible with 68010 and up, the code must do a run-time check for CPU model and decide whether to use MOVEC or not.

A common problem is that in order to compile this for 68000, the MOVEC instruction must not be in the code.

movec VBR,d0 is equivalent to dc.l $4e7a0801.

The compiler or assembler must then (in the part of the code that should execute a MOVEC) support in-line data.

If it doesn't, you can put the word sequence 0x4e7a, 0x0801, 0x4e73 in a data area, get the starting address, and Supervisor() to it. ($4e73 is equivalent to RTE)

[Csoft]

Hello guys,

I'm working on a game written in C with a custom built framework I wrote. I'm adding a music to my game and I'm trying to use this fantastic ptplayer routine, but I don't want to use mt_playfx function, since my framework already have it's own sound playing functions.

My music uses 0,1,2 channels, the 3 channel is reserved for sound fx, but when I try to play sound on 3rd channel it plays very bad with strange noises.

Is there a way to make ptplayer routine to completely ignore channel 3 and let my code handle it in his own way? I made a similar thing with the p61 routine in assembly.

Thank you in advance.

Lorenzo

P.S: This is a cut/paste of a mail I just send to the author, didn't find this thread before, sorry to the author for the double request.

[jotd]

you can reserve tracks for music with the api, and block a channel. But that works in the player itself (since it handles music). You could have conflicts with external sound play.

I think what you experienced is normal and can't be changed. But let me tell you one thing: I adapted Supercars 2 sound replay (so I was able to set music in-game) to ptplayer, keeping the original sound data as is (as I kept the original sound routines when music was off and engine was on, engine is special looped/variable frequency sfx that you can't really process with ptplayer).

So maybe it's not such a big effort to adapt your sfx play to the ptplayer code. Just wrap the mt_playfx in your framework and you'll only have minor changes to perform

[phx]

I already replied to Lorenzo's mail and the answer is that you cannot rely on ptplayer not to touch any of a channel's registers, even when no music is played on it. (This could be improved in future.)

The TimerB interrupt handler always sets all sample pointers and lengths, and the player might rewrite the last known period on every step.

So the solution might be to comment the two lines writing to AUD3LC and AUD3LEN in mt_TimerBsetrep, as well as the call to mt_playvoice for the channel #3.

[Csoft]

Originally Posted by phx

I already replied to Lorenzo's mail and the answer is that you cannot rely on ptplayer not to touch any of a channel's registers, even when no music is played on it. (This could be improved in future.)

The TimerB interrupt handler always sets all sample pointers and lengths, and the player might rewrite the last known period on every step.

So the solution might be to comment the two lines writing to AUD3LC and AUD3LEN in mt_TimerBsetrep, as well as the call to mt_playvoice for the channel #3.

This partially worked as I said in the second email, it plays the sample without bad noises, but screws up the playback frequency/period of my sample, which is played with a very low frequency. I think that it could be a good idea to have the option to "ignore" one or more channel, but in the meantime I decided to merge the two approaches.

If I see that mt_Enable is false, I play sound with my code, otherwise I play it with mt_playfx. This is not what I wanted to do initially, nor the most clean approach but it works.

Thank you for your help!

Best regards,

Lorenzo

[alpyre]

This is a noob question but what is the mathematical connection between the sampling frequency of the sample and sfx_per?

Originally Posted by phx

Your sox-call with "--encoding unsigned" is likely wrong. I'm using my own portable converter (tools/wavtoraw.c in all my published game sources) which converts to mono at 11025Hz. Then I can play these samples with a period of 320.

I understand for 11025Hz 320 is ok. But what about other frequencies? Is it 640 for 22050 and 1280 for 44100? How should we calculate it for any sampling frequency?

[roondar]

The period value is actually based on the custom chip set clock, which is around 3.58MHz for PAL systems and 3.55MHz for NTSC systems. Here's an example to show how it works:

PAL_cycles 		=	3546895
NTSC_cycles		=	3579545
PAL_period 		=	PAL_cycles/desired_frequency
NTSC_period		=	NTSC_cycles/desired_frequency

PAL_period 		=	PAL_cycles/11025 = 321
PAL_period 		=	PAL_cycles/22050 = 161
PAL_period 		=	PAL_cycles/28000 = 126

Etc
Note that the Amiga systems are normally limited to around 28KHz, though ECS/AGA systems can do 56KHz if the system is using the VGA like resolutions (i.e. DBLPAL/DBLNTSC).

[Photon]

Originally Posted by alpyre

This is a noob question but what is the mathematical connection between the sampling frequency of the sample and sfx_per?

I understand for 11025Hz 320 is ok. But what about other frequencies? Is it 640 for 22050 and 1280 for 44100? How should we calculate it for any sampling frequency?

Yes, what is called period is simply the time interval between subsequent samples in the sample(d sound), and the rate is how many periods in a second.

Period and rate are opposites, so the relationship is 1/x, essentially 1/T, multiplied by the timer interval (counted against some clock frequency) that all (sampled) sound chips have. So yes, a doubling in period is exactly a halving of frequency, on all sampled sound chips.

Details and comparison with fixed-period sound chips + links

[alpyre]

Thanks for the swift answers people. If I get it correctly the value is paula's hardware cycles per sample (cycles/sample).

Now what I cannot wrap my head around is the value vh_SamplesPerHiCycle in struct VoiceHeader. The struct is for loading and playing 8SVX sound samples.

Devices manual says this value is (samples/cycle). The vaule is an ULONG integer? How can there be an integer value of samples per cycle? I guess the term "cycle" there stands for something else?

I've read this part over and over and still couldn't figure out what this value is used for?
https://amigadev.elowar.com/read/ADC.../node02CD.html

I want to be able to play any 8SVX file in their intended pitch. Can I safely ignore this value?

[Lisiak4]

Supr, with permission I will use finetune tables from the source code. I tried to do it myself without tables from a few calculations, but in the end nothing usable for me...

Thank you!