you are disabling

1if (!(val&0x20))  return;

Is this intentional ?

Yes, I'm not entirely sure why it's there - I *think* the logic is wrong (the "!" isn't meant to be there) in which case enabling the percussive instruments would trigger the recording, but this would mean that in most cases it would start too early. (Not to mention a whole bunch of other unrelated OPL settings would trigger the recording to start early as well.)

The extra condition I added is a more accurate replacement for that line, had it been correct to start off with. Feel free to remove that line altogether if you'd prefer.

EDIT: No wait, sorry, the logic is correct, but that first line renders it useless. 0x20 is only important when cmd==0xbd, but as you can see from the first condition the code will never reach that line when cmd==0xbd. My original points about starting the recording too early still apply though.

I apologize in advance for whatever inconveniences I may cause in reviving this thread, but I'm experiencing the exact error in my OPL captures which Malvineous' patch addresses. I'm acquainted with DosBox itself, but pertaining to programming knowledge, I possess none thereof to attempt applying his patch. Therefore, I wanted to inquire as to if his patch will ever be incorporated into future versions of DosBox, or if someone gracious enough could assemble Malvineous' patch. Thank you.

It's already fixed.

I'm using DosBox 0.72 on Windows Vista 64-bit, and use Adplug for Winamp as playback for the recorded OPL. I'm unsure whatever could be the source of the problem, as I've been experimenting with different versions of Adplug, and aside from this error, everything's functional on Vista 64-bit.

It's not in 0.72. Also i'm not sure if adplug can handle the new dro format yet.

Could you possibly redirect me to either an official or unofficial DosBox build that contains the patch?

Adplug seems to work fine with the .dro, but on rare occasions, the speed of the music is slower than average, which is usually corrected by reverting to an earlier version of AdPlug.

Just use a recent build (yesterday/today). The commit by Harekiet was quite
a few weeks ago though.

adplug probably can't play the files though. as the format has been changed significantly

Yes but recording is SO much more fun than playing it back 😀

thanks

adplay/adplug can't play alot of formats properly, not even cmf 🙁

Did you send cmf files that it doesn't play correctly to the author?

"adplay/adplug can't play alot of formats properly, not even cmf"

TD2192 ?-)

wd wrote:

Did you send cmf files that it doesn't play correctly to the author?

...every cmf file? I can't find one that plays remotely correctly.
Maybe he needs playcmf for reference
a real very obvious bugger is funky.cmf. no drums!!

Maybe check the sources where the cmf player comes from/if it's the same
format that you're feeding it/if there are notes that it's working/complete/whatever.

Funny I should stumble across this again - I actually fixed the CMF playback problem a week or two ago and sent a patch to the AdPlug author - it's in CVS now, so the next release will play funky.cmf and the others properly. (Or you could build the CVS version of course!)

I also might be to blame with the .dro speed issue. I found a little while back that the .dro format had changed (the header became one byte longer or something) and I sent a patch through to fix this in AdPlug. I think the side effect was that older .dro files had tempo issues, but IIRC all new .dros were using the newer format so we stuck with the patch.

Has the .dro format changed again?

the dro version number has changed i think. A lot of changes have happened to it since 0.72

Hi friends,

I downloaded a recent build, with the new dro format.

Although the capturing routine is much better than the earlier version, I still cannot capture the demo and intro from Dune 1 properly...