I found that amd.c is missing tracker.h.
I also tried 000.ply and found that only a few tracks can be played normally.
You're trying already players which are beta at most So yes, these ones still need work to get them correct. I just synchronize the sources online to have a backup but they are not part of the released set of players yet.
Regarding the Enigma mod: that's indeed a bug, and it looks like it only happens the first time. If you play the mod again it sounds correct (at least at my setup). Looks like something is not initialized correct at first.
Would it be possible to get standard midi .mid support where the midi messages are outputted to a midi interface? For playing on an external sound module.
Also, a support for playing 1bit sound tracks. (Don't know what the standard formats are).
Both roboamad and roboplay midi will have slower music. Can you explain why?
Would it be possible to get standard midi .mid support where the midi messages are outputted to a midi interface? For playing on an external sound module.
Also, a support for playing 1bit sound tracks. (Don't know what the standard formats are).
For the midi output: probably not that hard to add, in fact I was already looking into adding support for MidiPAC (and maybe other interfaces). It basically means adapting either the current OPL4 fm or wavetable player and send the output to a port.
Regarding 1bit sound tracks, that's an interesting, there are indeed some standards for that.
Both roboamad and roboplay midi will have slower music. Can you explain why?
For RoboAmad i'm not aware (yet) of any slowdown. For midi playback on OPL4 wavetable lots of optimization probably is still possible (For example move to native assembly for certain parts). Initial step was just to get it working. The overhead of using C for sure slows it down now. I already have some code from mrc member MSD to further optimize, now just a matter of finding the time
With midi, there are so many different interfaces, supporting them by detecting and setting them up in code is a lot of work. I guess the user(programmer) can do that. If the detection is provided, sometimes it can be annoying, might be nicer to allow manual selection by the user. Had this experience a few times when I built my own clone sound cartridges and want to use programs like vgmplay or midry, where the program can't detect and accept the clone hardware. So with midi, it would be nice if the user can just select a io port for data output.
Sounds like a good idea indeed, however it could be that different hardware needs different initialization. So could be even a bit more extended to e.g. a simple config file stating port number and data to setup the interface and port number for the midi data.
Had this experience a few times when I built my own clone sound cartridges and want to use programs like vgmplay or midry, where the program can't detect and accept the clone hardware. So with midi, it would be nice if the user can just select a io port for data output.
“The source is open and can be freely modified to suit your specific case.”
That solution works well for VGMPlay. Many have made a customized build for their homebrew hardware. While I focus my efforts (and memory space) on the hardware widely available to the general public.
Thank you, VGMPlay is great. I will have to take a look at the source.
Roboamad does play slower. I don’t know if it’s my player version. For example, avtak.ama, after playing for one second, the speed will become half or even slower.