Audacious

Yes, Audacious has gone through a lot of refactoring over the years, and trying to maintain compatibility with both old and new releases would be difficult.

Can the core ASAP code (asap.c and asap.h, I guess) be built as a shared library? Linking to a shared library which will be updated separately would be better than embedding a copy of the emulator into audacious-plugins, where it would likely get out of date relative to the current ASAP version.

Also, do you have a test file you could attach or email? Just so I can make sure that I don't break anything in the course of updating the plugin.

Structures are opaque, but I plan to make breaking changes in the interface (although it didn't happen in the last three years).

There are about two releases of ASAP a year. If we go with copy of ASAP in audacious-plugins, I can notify you of new releases.

For sample files, see the "Input formats" section of http://asap.sourceforge.net/
ASMA is a huge archive of SAP files and http://asap.sourceforge.net/examples.zip is a tiny set of files in different formats.

Apparently asap.c and asap.h are code generator output (http://cito.sourceforge.net/)? I don't want to include machine generated code in audacious-plugins, especially if the code generator is not well-known and commonly available.

What's wrong with generated C code? To re-generate it, you'd need:
- cito (written in C#)
- xasm (written in D)
- mads (written in Pascal)

Releasing machine-generated code means it is not maintainable (by me or anyone else) without going to extra effort to download, compile, and install the code generator. The overhead will easily double the time it takes to fix a bug in the code, even ignoring the possibility that the code generator itself has bugs in it.

C++ is a well-known, standardized, and extensively used language, and there are industry-grade compilers readily available on every version of UNIX around. In my opinion, that's a good enough reason to choose it over the latest "new and improved" language or language variant. You can use whatever language you want in your own projects, but if it's going to be included with audacious-plugins, it should be in C++.

I don't see why this plugin is necessary. The Game_Music_Box-based plugin I made ages ago supports SAP files natively. If there is a fault with the emulation, myself or blargg would like to know about it.

It's the first time I hear about Game_Music_Box. Apparently it bases on Game_Music_Emu, which is well known to me.

Let me list some differences between GME and ASAP:
- GME doesn't recognize "TIME" tags. All songs are of fixed duration.
- GME doesn't open "TYPE D" SAP files. There are hundreds of such files.
- GME's emulation of POKEY is inaccurate. Several tunes sound "broken". Example: Boremloza.sap from 1:30 - compare ASAP and GME playback.
- GME doesn't support editing SAP metadata.
- GME doesn't provide GTIA nor COVOX playback.
- GME doesn't support NTSC clock.
- ASAP emulates all 256 6502 opcodes.
- In addition to SAP, ASAP opens 12 other file formats native to Atari 8-bit computers.

Please correct me if I'm wrong.

John: I understand your point. Can we go the shared library way? The interface would be asap.h and the ASAP shared library will be maintained and distributed by me.

Piotr Fusik wrote:

John: I understand your point. Can we go the shared library way? The interface would be asap.h and the ASAP shared library will be maintained and distributed by me.

That would be fine with me.

I added TIME tag support very recently.

If you would like to go into more detail as to how Boremloza.sap is different, then I would be willing to hear you out there.

I think adding DigiMusic support would not be very difficult, it is something I could likely do in an afternoon. I am also not convinced on why providing an NTSC clock is important, although we already track scanlines, so I am pretty sure we could add this feature if proven useful.

Thusly, I do not think this is really worth our time vs. improving the current plugin.

I keep my fingers crossed for better SAP playback in GME.

Boremloza has unusual bass line. Two divisors are joined into 16-bit one, but the volume is set on both channels.