Protracker playback library with sound effects

[idrougge]

An update to the latest version of Phx's library is probably overdue. :/

[MickGyver]

Originally Posted by idrougge

An update to the latest version of Phx's library is probably overdue. :/

I used a diff tool in an attempt to build a 5.3 version of this library. Got nowhere though. I'm not familiar with assemblers, I tried Asm-One, but get an error at the first astatement, next line "args word,byte" throws an error: "Illegal operand". What assembler did you use to build this and what extra steps would one need to take?

Attached is the updated source if you want to try and build it.

[MickGyver]

I tried VASM, there I get a few errors about missing symbols (runerrs, _soundobjectcheck and _volumecheck). Searched the sources and it seems that those symbols are indeed missing.

EDIT: I replaced the symbol names with zeroes, it then compiles, I get no errors when I run an example, but only get silence. Building the source on GitHub with vasm also results in just silence, no errors or crashes. Maybe that version you (idrougge) uploaded to GitHub is an older unfinished version?

error 3009 in line 7 of "libheader": undefined symbol <runerrs> at CODE+0x2c, reloc type 1
        called from line 112 of "ptplayer.asm"
>            Dc.l    \4,0,0,0,\5

error 3009 in line 2 of "subs": undefined symbol <_soundobjectcheck> at CODE+0x202, reloc type 1
        called from line 153 of "ptplayer.asm"
>            Dc.w    \2

error 3009 in line 2 of "subs": undefined symbol <_volumecheck> at CODE+0x270, reloc type 1
        called from line 159 of "ptplayer.asm"
>            Dc.w    \2

[MickGyver]

Since I couldn't get any sound from idrougge's source when compiling with VASM, I started from "scratch" with the v5.3 source and referenced the library source based on v5.0 by idrougge. This version might still need some fixes, I have not tested everything thoroughly yet.

Attached is version 5.3 of the bb2 library, with an added statement (below). All the statements from v5.0 work but the author of the original library (phx) recommends to use the new MTPlayFX statement instead of MTSoundFX.

New statement and newtype to use with it

MTPlayFX sfxStructAddress.l

NEWTYPE .sfx
  sfxPtr.l ; Pointer to sample start in chip ram, even address
  sfxLen.w ; Sample length
  sfxPer.w ; Hardware replay period for sample
  sfxVol.w ; Volume 0..64, is unaffected by the song's master volume
  sfxCha.b ; 0..3 selected replay channel, -1 selects best channel
  sfxPri.b ; unsigned priority, must be non-zero
End NEWTYPE

The archive includes an include file with the sfx structure as a newtype, and a statement to initialize the newtype from a sound object. Also included is the source, an example and a .bat file with the command used to compile the library using VASM.

Changelog (for the original library)

5.1:
- Included C header file, ptplayer.h, provided by BSzili.
- Fixed bug where other level 6 interrupts could trigger sample replay.
- Eliminated relocations in the fine-tune table, by replacing pointers
  with word-offsets (asman).
- More optimizations in the Timer B interrupt handlers and made it
  PC-relative (asman).
- Include a public domain license.

5.2:
- Make it work with broken mods, which have a sample repeat length of zero.
- Never break looped samples with sound effects, except we have looped
  samples on all four channels at once!
- New variable _mt_SongEnd to automatically stop the song when having
  played the last position. Don't use it! Doesn't work perfectly yet.

5.3:
- No longer clear the first word of each sample for idle looping.
  Either we have a good Amiga tracker MOD with repeat-length one, which
  already cleared that word, or we have a PC tracker MOD with a zero
  repeat length. In the latter case the idle loop will now point to
  address $0. Make sure that the word at this address is cleared!
- Treat samples with a length of one word the same as with zero length
  as a workaround for broken PC trackers.
- Changed APTR to void* in the C headers, for better Kickstart 1.x
  OS header file compatibility.
- Fixed detection of negative fine-tuning (broken due to optimizations
  in V5.1).

[Daedalus]

Excellent, thanks! I'll try this library out in a project I'm working on (when I have the time...)

The first change about not clearing the first word: Is that fixing an issue I think I had with the older version where certain sound effects were getting stuck playing a high pitched note? I hadn't gotten around to clearing the first two bytes of the sample to confirm it...

[Cobe]

Fabulous!
I've just fiddled with the example and it works.
sfxCha.b was exactly what I missed in previous version.
Thanks!

[MickGyver]

Originally Posted by Daedalus

The first change about not clearing the first word: Is that fixing an issue I think I had with the older version where certain sound effects were getting stuck playing a high pitched note? I hadn't gotten around to clearing the first two bytes of the sample to confirm it...

I have no idea to be honest, I still think the first word needs to be cleared. It has got something to do with it, that's for sure.

[phx]

Originally Posted by Daedalus

The first change about not clearing the first word: Is that fixing an issue I think I had with the older version where certain sound effects were getting stuck playing a high pitched note? I hadn't gotten around to clearing the first two bytes of the sample to confirm it...

This was probably a PC-tracker MOD with a zero repeat-length (which doesn't happen in original Amiga MODs). A zero repeat length was just increased to two, as a workaround, before 5.3. As a consequence this required the first word to be zero, which usually is not the case in PC-MODs. As a result it is playing the high pitched noise there, as long as you don't clear the word yourself.

To conclude: Yes, this should hopefully be fixed with 5.3.

[Daedalus]

That's great, thanks for the detailed explanation And, of course, your work on the original library!

[idrougge]

Originally Posted by MickGyver

I used a diff tool in an attempt to build a 5.3 version of this library. Got nowhere though. I'm not familiar with assemblers, I tried Asm-One, but get an error at the first astatement, next line "args word,byte" throws an error: "Illegal operand". What assembler did you use to build this and what extra steps would one need to take?[/S]

I used PhxAss, by Phx himself.

[earok]

Thanks for the updates! Amazing work all

I still had some issues with high pitch after some samples, but I didn't know about the first word thing before. With this tiny tweak to the included sample function

Statement SFXInit {*fx.sfx, snd.w, vol.w, cha.b, pri.b}
  *_snd.sound=Addr Sound(snd)  ; Get the pointer to the sound
  Poke.w *_snd\_data,0 ; Set first word of sample data to 0
  *fx\sfxPtr=*_snd\_data       ; Copy the data
  *fx\sfxLen=*_snd\_length     ; ...
  *fx\sfxPer=*_snd\_period
  *fx\sfxVol=vol
  *fx\sfxCha=cha
  *fx\sfxPri=pri
End Statement

Everything came right for me

[MickGyver]

Originally Posted by earok

Thanks for the updates! Amazing work all

I still had some issues with high pitch after some samples, but I didn't know about the first word thing before. With this tiny tweak to the included sample function

Statement SFXInit {*fx.sfx, snd.w, vol.w, cha.b, pri.b}
  *_snd.sound=Addr Sound(snd)  ; Get the pointer to the sound
  Poke.w *_snd\_data,0 ; Set first word of sample data to 0
  *fx\sfxPtr=*_snd\_data       ; Copy the data
  *fx\sfxLen=*_snd\_length     ; ...
  *fx\sfxPer=*_snd\_period
  *fx\sfxVol=vol
  *fx\sfxCha=cha
  *fx\sfxPri=pri
End Statement

Everything came right for me

Cheers! By the way, you should be able to use MTInstall 1=PAL/0=NTSC with this version and you NEED to call MTRemove when you want to remove the CIA player from the system.

[earok]

Originally Posted by MickGyver

Cheers! By the way, you should be able to use MTInstall 1=PAL/2=NTSC with this version and you NEED to call MTRemove when you want to remove the CIA player from the system.

Thanks for the heads up!

[MickGyver]

Originally Posted by earok

Thanks for the heads up!

For MTInstall, it is 1 for PAL and 0 for NTSC, I corrected my post above.

[earok]

I recently released a port of Raid Over Moscow using this library, but it seems that there's some cases where audio doesn't work at all, I've got no idea if it's an issue I've caused or not. It appears the common thread is towered A1200's with sound cards. I know almost nothing about AHI and sound cards so I have no idea what to try, any suggestions would be appreciated!



Raid Over Moscow thread: http://eab.abime.net/showthread.php?...67#post1367467

[jotd]

I cross build the ptplayer lib with vasm without issues:

vasmm68k_mot -devpac -Faout -o ptplayer.o ptplayer.asm

[phx]

Originally Posted by earok

I recently released a port of Raid Over Moscow using this library, but it seems that there's some cases where audio doesn't work at all, I've got no idea if it's an issue I've caused or not. It appears the common thread is towered A1200's with sound cards. I know almost nothing about AHI and sound cards so I have no idea what to try, any suggestions would be appreciated!

Ptplayer was designed for games which take over the system. It doesn't use the OS and programs Paula's hardware registers directly, so it will never work with AHI or any other sound hardware than Paula.

I have never seen an Amiga sound card, and I don't even understand why you need one in an Amiga, but from what I have read, some sound cards can use the Paula-output as external input (into their mixer?). Probably this won't work either when it requires any OS support.

Originally Posted by jotd

vasmm68k_mot -devpac -Faout -o ptplayer.o ptplayer.asm

BTW, -devpac is suboptimal when assembling ptplayer.asm, as it disables all optimizations. And I always write code which relys on assembler optimizations (mostly branch sizes).

[daxb]

As far as I know AHI and Paula direct are independent from each other. So if the library don't use AHI then it shouldn't responsible for audio issues.

Edit: phx was faster.

[earok]

Thanks guys.

As I understand it, Paula feeds audio directly into the sound card so (for example) WHDLoad games still output audio.

My current line of thinking is that it's to do with how I'm dropping in-and-out of OS friendly mode to load from disk when needed, though I'm not sure why it'd only affect some machines. I'll try some things for the next build.

[jotd]

problem when you want to be 100% user friendly it's very difficult to achieve performance or perform things that you can so more easily with hardware banging (reading joysticks, double buffering, blitting). I'm sure AHI interface is super simple stream based and works perfect with a sound card, but so few games will benefit from it.

no wonder why all great games from the golden era were asm+hardware banging. Personally I'd recommend C or C++ instead of asm. You never have register size issues, register corruption, custom write size errors, ... Problem is: it creates much bigger executables. Once again paying for simplicity...