Ambiguous thread titles are dumb.

This is what happens when a hopelessly depressed individual vents his current frustrations on a public forum.

But really, I don't understand why this github with adplug related stuff, the adplay-unix package is all hardcoded and is not aware of the 3rd emulation core that's in the adplug library now.

Probably to satisfy some Debian "security first" concerns where the only changes allowed are paranoid buffer overrun fixes.

https://github.com/adplug/adplay-unix/blob/ma … r/src/adplay.cc
"authored on Jan 1, 2010"

1/***** Typedefs *****/
2
3typedef enum { Emu_Satoh, Emu_Ken } EmuType;

https://github.com/adplug/adplug

on Feb 11, 2014 Added WoodyOPL from the DOSBox team.

*sighs*......................................................

A small thread bump:

I think I know the feeling, when you get the impression that something you've been interested in is finally available in a certain form you have in your mind, only to find out this is not exactly the case.

Still, this is probably the consequence of adplug and its satellite projects (like adplay-unix) being worked on as a hobby, and also not really updated for long.

Adding a bit more about this, I'm not sure how much testing has been done. Based on the mention of the years 2002-2008 in the copyright notice, in the current copy of woodyopl.cpp from the adplug repository (https://github.com/adplug/adplug/blob/master/ … rc/woodyopl.cpp), it's apparently older even than the revision of the same OPL emulator as originally added to the DOSBox codebase: http://sourceforge.net/p/dosbox/code-0/3936/l … ardware/opl.cpp

Hi all,

NY00123 pointed this thread out to me, as I'm the one responsible for moving AdPlug off SourceForge and over to GitHub.

The reason for the move was simply because SourceForge has begun taking over certain projects and modifying the downloads to include adware and other questionable practices. So along with many other projects, we moved to GitHub as (for the time being at least) they are much more trustworthy.

I haven't worked much with the AdPlug codebase, but with regards to WoodyOPL as far as I can tell, this is not the current DOSBox OPL synth. DOSBox currently has a new synth written from scratch by the DOSBox team called DBOPL. Before this new synth, they were using an improved version of Ken Silverman's synth, and it's an early version of this which is in AdPlug and named "WoodyOPL" for some reason.

So what this means is that if you were to update AdPlug to the latest version of WoodyOPL, then all you'd get is the old DOSBox synth that is no longer in use because it's not accurate enough. Although it was fairly good in the end, I'm not sure that's worth the effort.

It would be much better to get the current DOSBox OPL synth (DBOPL) in there instead, but this is difficult because AdPlug is licensed under the LGPL, while DBOPL is GPL. If you're not familiar with LGPL vs GPL, then basically, you can't put GPL code (like DBOPL) into an LGPL project (like AdPlug). You can go the other way, but putting AdPlug code into DOSBox would be of limited use...

For a number of years AdPlug has included the MAME synth, even though it is under a similarly incompatible licence, and this was worked around by providing patches on a different website. I guess there's nothing stopping a similar arrangement with DBOPL, if someone has the time to do it all. In fact, looking at this closer, you can include LGPL code in a GPL project, which means you could fork the AdPlug project, change it to GPL, add the DOSBox synth, and release the whole thing as a GPL version of AdPlug. The files which were originally LGPL (i.e. everything except the DOSBox synth) would stay under that licence, but the new project as a whole would be GPL. Then you wouldn't need any weird hosting arrangements, you'd just have a fork of AdPlug. That could be the way to go...

Any volunteers? 😉

Hey Malvineous,

Good that you've come to tell a bit about the relocation to GitHub!

I can see there are a few bits of more potential confusion. Back in 2009, two OPL emulators were added to DOSBox: The "integer dosbox opl" (i.e., DBOPL) and the "alternative opl2/opl3 emulator" (WoodyOPL, based on Ken's emulator): http://sourceforge.net/p/dosbox/code-0/3355/l … c%2Fhardware%2F

The change above is also mentioned in the changelog for DOSBox v0.73. Before these two OPL emulators were added to DOSBox (so covering DOSBox v0.72 and earlier releases), some version of fmopl (from the MAME project) was used. As I think that at least some readers should know by now, while certain old versions of fmopl may be licensed under GPL (or compatible) terms, this is clearly not the case for later releases, where commercial exploitation is basically disallowed.

Regarding the idea of including DBOPL in a fork of AdPlug, I'm not sure there's a great motivation do that, rather than including WoodyOPL. Reason is, not only WoodyOPL is available under LGPL terms, but it may actually lead to sound output closer to the "real thing" than DBOPL in certain circumstances. The DBOPL core is the default choice in DOSBox because it's the faster one.

Malvineous wrote:

For a number of years AdPlug has included the MAME synth, even though it is under a similarly incompatible licence, and this was worked around by providing patches on a different website.

We're working on fixing this licensing situation, but the primary developer of this code hasn't responded to our request for relicensing, so we may have to implement a brand-new emulation based on some of the latest reverse engineering. (Also, as I've explained many times before, I'm partly to blame for this situation so I'm really focused on what we're going to do to fix it. 😀 ) I'm one of the local MAMEDev's here on VOGONS, howdy. 😀

Stiletto, which latest reverse engineering you mean?

Can you also give your opinion what properties should a next-gen OPL emulator core have? I mainly mean regarding licence (GPL/BSD/other? Which GPL/BSD version?) and programming language (C/C++/other? Which standard?), and other aspects, so that it would not only be used in some small example music player and it would be useful and interesting enough for other larger projects as well to utilize.

Some ideas seen along the road has been a DLL so each time a different or improved emulator is released, a player only needs a new DLL. But it was not so successful. Another thing is that projects using an emulator as source code won't necessarily update it too often, so it should be easily pullable from a central repository.

Licence-wise MAMEDEV is trying to move towards using GPL (2.0+) for the overall project, and preferably BSD (3-clause) for shared components like sound emulation although not every developer is in favour of BSD so it will probably end up depending on the author of each component.