BZR Player - a new music player for Win

[mai]

Originally Posted by bLAZER

I meant remove .me from the settings i BZR Player. I will of course fix the bug for the next version since it should be .me.

Thanks, it works now!
I was not aware, that it has something to do with the "Ignore Filetypes" setting, removing "me" solves the problem.

[meynaf]

Quartet ST support doesn't work properly.
You're using Don Adan's player, aren't you ? But alas it doesn't play them correctly (try the mod from "fire & brimstone", it's awful). He took my code before i debugged it...

Btw. Normal file naming is .4v and .set, not qts and smp. I had the software back in my Atari days so i know this, but Don Adan refused to change (he rarely listens to me ).

[bLAZER]

I'm using the player that was bundled with UADE, so now sure which one that is. I'm not sure how that "fire & brimstone" should sound...no obvious disaster in my ears. So is there a better player?

[Vot]

Originally Posted by bLAZER

I'm using the player that was bundled with UADE, so now sure which one that is. I'm not sure how that "fire & brimstone" should sound...no obvious disaster in my ears. So is there a better player?

The native player on an amiga. ?

[meynaf]

Originally Posted by bLAZER

I'm using the player that was bundled with UADE, so now sure which one that is. I'm not sure how that "fire & brimstone" should sound...no obvious disaster in my ears. So is there a better player?

Try my player under Delitracker2 on the Amiga (works best with a good 14-bit noteplayer). If you can't hear the difference, you shouldn't be writing a music player at all

This format goes wildly out of 28khz range, and often bypasses even 56khz, so the noteplayer interface is mandatory.
Note that the tcb tracker has the same problems.
If it were possible to define bzr's own noteplayer interface and make it available for 68k code, i'd gladly change my players to use it.

Originally Posted by Vot

The native player on an amiga. ?

The best really is the native player on an Atari (i.e. the game). It's Quartet ST, remember
EP's player by Don Adan (the one used here in bzr) is based on old code from me, and is unable to play them properly.

[mai]

Protracker and its Packer
Not an issue/problem this time, just noticed, that BZR cant recognize ziks, where the ID is changed.
For example those M.K. on offset 438 for Protracker.
or SNT! on offset 0 for ProRunner 2.0.
If there is different ID, BZR cant recognize!

[bLAZER]

Originally Posted by meynaf

Try my player under Delitracker2 on the Amiga (works best with a good 14-bit noteplayer). If you can't hear the difference, you shouldn't be writing a music player at all

This format goes wildly out of 28khz range, and often bypasses even 56khz, so the noteplayer interface is mandatory.
Note that the tcb tracker has the same problems.
If it were possible to define bzr's own noteplayer interface and make it available for 68k code, i'd gladly change my players to use it.



The best really is the native player on an Atari (i.e. the game). It's Quartet ST, remember
EP's player by Don Adan (the one used here in bzr) is based on old code from me, and is unable to play them properly.

What does the "14-bit noteplayer" do?

I guess you can't use Deliplayers in UADE/Eageplayer so that doesn't help me much...how much work is it to fix your Eagleplayer?

[meynaf]

Originally Posted by bLAZER

What does the "14-bit noteplayer" do?

Play more than 4ch with high quality (better than most players on pc).
Play sounds with freq >28khz (even >56khz), which is necessary here.

Originally Posted by bLAZER

I guess you can't use Deliplayers in UADE/Eageplayer so that doesn't help me much...how much work is it to fix your Eagleplayer?

I guess converting the DT noteplayer to EP noteplayer would work... if EP noteplayer supports the relevant features. I have only a very small knowledge about EP noteplayer, btw.

I'd prefer hacking UADE for support of DT2 noteplayer, though (or having a "direct" noteplayer interface from UADE into BZR).

[bLAZER]

Well go ahead and hack UADE then

Even better would be if you write a new player in c/c++ that just render the sound to a buffer. Either from scratch or maybe using libxmp. I'm not sure how much in common Quartet have with .mod and if it needs a lot of hardware emulation?

[meynaf]

Originally Posted by bLAZER

Well go ahead and hack UADE then

Well, i've just seen the sources, and... errh... *cough*

Originally Posted by bLAZER

Even better would be if you write a new player in c/c++ that just render the sound to a buffer. Either from scratch or maybe using libxmp.

Render the sound to a buffer, huh ? It doesn't work this way. That would involve channel mixing, which shouldn't be done in the player itself. This format is sound tracker, not streamed audio.

Filling in a structure saying which samples to play for each channel, is quite easy though (but is better done in 68k asm, i don't like c/c++ too much).
Getting rid of the dt noteplayer isn't very hard, this is what i did for the embedded quartet st player in my Back to the Golden Age game port (to replace it by my own, obviously).

Originally Posted by bLAZER

I'm not sure how much in common Quartet have with .mod and if it needs a lot of hardware emulation?

Quartet is very simple, actually. Only 4 channels, not many effects. It's just that it goes quite high in sample replay frequencies.
The situation is quite similar for tcb tracker, btw.

It only needs :
- check routine
- extload
- initnote (this routine computes max freq for the noteplayer, quartet can sometimes go over 65khz !)
- init module (f.e. performs sample conversion from unsigned to signed)
- normal init routine (to start or restart playing)
- interrupt routine (200hz usually, sometimes 50), fills in note struct and calls song end routine

The best way to handle the situation would be a direct interface between BZR and the 68k code. By supporting 68k players directly you would get rid of many problems in both sc68 and uade.
(You can count on me for turning regular dt/ep players into a new custom way.)

[bLAZER]

Originally Posted by meynaf

Render the sound to a buffer, huh ? It doesn't work this way. That would involve channel mixing, which shouldn't be done in the player itself. This format is sound tracker, not streamed audio.

Not sure I understand...all the sound libs I use have a method like fillbuffer (void* buf) which you call to get the audio rendered from the lib. However if it's close to TCB tracker you could take a look at libxmp, there's a half working tcb player there. Maybe you could use that to build for.

Originally Posted by meynaf

The best way to handle the situation would be a direct interface between BZR and the 68k code. By supporting 68k players directly you would get rid of many problems in both sc68 and uade.
(You can count on me for turning regular dt/ep players into a new custom way.)

Well I use FMOD as the sound engine so it doesn't really have to be custom for BZR Player. I don't know much assembly but I'm of course positive for a library/player if it has good potential.

[meynaf]

Originally Posted by bLAZER

Not sure I understand...all the sound libs I use have a method like fillbuffer (void* buf) which you call to get the audio rendered from the lib.

And thus all the sound libs you use have their own internal mixing code, with various quality and different settings. That's a little bit uncomfortable for users to set things such as "replay freq" multiple times...

A player (using a note player interface), on the other hand, just fills in a structure saying, for each channel, the addr/size of the sample, its period and volume, and eventual repeat/replen values.
Then the mixing is left to other parts of the software.

Originally Posted by bLAZER

However if it's close to TCB tracker you could take a look at libxmp, there's a half working tcb player there. Maybe you could use that to build for.

I think i can guess why their tcb player is half-working...
Anyway, nothing in the libxmp docs i've found says how to integrate a new format into it. They just say how to use the lib to play things.

Originally Posted by bLAZER

Well I use FMOD as the sound engine so it doesn't really have to be custom for BZR Player. I don't know much assembly but I'm of course positive for a library/player if it has good potential.

Same situation as libxmp, no doc found about FMOD internal stuff, which would allow fixing/adding replayers.


The main problem you seem to have here with BZR is that you can only forward replay problems to the lib's authors, and hope that you'll get a fix - and if you get no fix, you can just yell like hell

I have a good knowledge about Amiga's DT, enough to write a noteplayer myself (actually i really did it, to test my audio dma wait code).
But my knowledge about EP's specific stuff is close to nil.
Both DT and EP are no longer developed. They have little or no direct support for streamed audio, and no support at all for 16-bit samples.
Maybe it is time to write a brand new system ?

Are you able to integrate a simple 68k emu that would just be allowed to call some helper routines you provide, and fill in some structures ?
(i.e. just 68k, no hardware emu, no os calls done)

[bLAZER]

There's pretty much only one guy doing the main work for libxmp, but I think he'll be glad with any help he can get. I mean you could take a look at the code. Every format basically has it's own loader with will fill a datastructure that's played by the one and only super mod player

FMOD's internal code is closed source. Take a look at the code of my very old Game Music Emu plugin to see how it works. I'm sure you cold do pretty much anything you want.

Sure, I'm dependent of several other programmers. But there is NO ONE with knowledge and time to write all those players by themselves anyways....and most are open source so anyone could fix bugs if they know how to.

[meynaf]

Originally Posted by bLAZER

There's pretty much only one guy doing the main work for libxmp, but I think he'll be glad with any help he can get. I mean you could take a look at the code. Every format basically has it's own loader with will fill a datastructure that's played by the one and only super mod player

Seems every "player" is just a converter. Strange formats will never work with such an interface - especially formats whose song end is more or less impossible to know, like snes spc700 rips.

Originally Posted by bLAZER

FMOD's internal code is closed source. Take a look at the code of my very old Game Music Emu plugin to see how it works. I'm sure you cold do pretty much anything you want.

Looks more like a streamed audio player than a tracker player.

Originally Posted by bLAZER

Sure, I'm dependent of several other programmers. But there is NO ONE with knowledge and time to write all those players by themselves anyways....and most are open source so anyone could fix bugs if they know how to.

Open source does not mean easy to modify

I have the knowledge and maybe even the time to convert many players to a new, more manageable interface. I could even make an Amiga version of the player so all the stuff would work everywhere.
However i really need a 68k (or 68k-like ?) interface, as converting asm players to C is a big burden for me (if not a pain in the a$$).

[bLAZER]

If I can help out let me know, but as I've said before I know nothing about assembler. You saw the interface for FMOD so that's what I have to work with.

[8bitbubsy]

The MOD replayer (libxmp) used in BZR Player is not that great for ProTracker MODs, and here's why:

- The InvertLoop (PT1.1+, "funkrepeat" in PT1.0) implementation sounds very off. F.ex. "teadrop in a pt.mod" by Daddy Freddy, and "delicate 0ooz!.mod" by emax.
- Sample swap (PT1.x/PT2.x but not 3.x/4.x) is not implemented, this means that swapping the voice's sample data without entering a note is impossible. This was used in *a lot* of PT MODs to simulate PWM on chiptune styled songs with basic waveforms. Also some songs accidentally use it (typo on sample number during 3xx, f.ex), and it will sound wrong in this player.
- The pattern jump/break implementation is nowhere near the one PT uses, so some quirky songs will get heavily broken. "black queen.mod" by Dreamer.
- The 9xx "offset add up" quirk is not implemented. "no-mercy.mod" by Alf. [Order #2, channel #4, row 48]. Try it in PT and be amazed. I also made a rather strange .MOD to demonstrate this (try in PT): https://dl.dropboxusercontent.com/u/4846123/insane.mod
- The 9xx overflow behavior is not like PT. In PT, if you have a looping sample and enter a 9xx offset that is after the loop end point, you should stop that voice, not wrap the pos in the mixer.
- Vibrato (4xy) is processed on all ticks, this is NOT PT behavior (all non-zero ticks).
- Tremolo (7xy) is processed on all ticks, this is NOT PT behavior (all non-zero ticks).
- "Glissando Control" (E3x) is not implemented. It will switch 3xx slides between smooth (E30 normal) and semitones (E31..E3F).
- Portamento (3xx) is reset if a new note is entered, even if the slide didn't finish. In PT, if you set a 3xx slide and it didn't reach the target period, then enter a new note and later continue the slide, it will in fact continue the previous slide and use the direction calculated from that 3xx (first). Kind of messy explaination but oh well.

I understand that it requires some heuristics coding to distinguish between PT and non-PT .MODs, but it's possible, just look at OpenMPT or kode54's modified playptmod.
I'm not expecting it to be perfect or anything, but being a perfectionist when it comes to PT MOD replayers myself, I tend to get a bit sad when I see replayers like this!

[bLAZER]

Thanks for this info. I'm sure libxmp strives to be better so I'll forward these bugs to the author and hopefully some/all will be fixed!

[meynaf]

Little problems to add to your list (or maybe not ).

I did not find the options to :
1. Loop on the playlist (as "repeat" loops on the module, not the list).
2. Move an entry to another place in the playlist.

Btw. If you want me to write some lib for you, you'd better provide me with some easy access to the sources (enough to compile it myself). Perhaps i have a few ideas, but i can't know how things might fit without having your sources (and check things if i can't compile them).

[bLAZER]

1. Not implemented
2. Not implemented

That would be great if you could. The easiest way would be to write an input plugin for FMOD using their minimal example player. That would also mean that other FMOD users can use your plugin.

So to start go to http://www.fmod.org/download-previous-products/ and download FMOD Ex. There's a folder with example projects included. One is called something like raw input plugin. It's basically just to include fmods header and link to the library and then create your plugin a compile to a dll (for windows that is). Then load the plugin using their minimal player. I could assist with more info/files/whatever if you want. Just let me know.

[meynaf]

Originally Posted by bLAZER

1. Not implemented
2. Not implemented

I'd never have guessed that

Originally Posted by bLAZER

That would be great if you could. The easiest way would be to write an input plugin for FMOD using their minimal example player. That would also mean that other FMOD users can use your plugin.

So to start go to http://www.fmod.org/download-previous-products/ and download FMOD Ex. There's a folder with example projects included. One is called something like raw input plugin. It's basically just to include fmods header and link to the library and then create your plugin a compile to a dll (for windows that is). Then load the plugin using their minimal player. I could assist with more info/files/whatever if you want. Just let me know.

But my goal would be precisely to get rid of the dependencies on such libs, not use them as basis...