I know I asked this on another forum but I don't think the answer you gave satisfactorily answered my question.
Are you (somewhat) taking up the challenge of creating a version of the plugin that can produce more accurate results and improve compatibility with previously problematic games? Or are you aiming to create a more featureful/portable version?
Now that Kirishima (sp) mentioned it, my Mario Party randomly crashes now. Same with some of the 'extra' tracks with DK64; I had to use HLE for those to even play then convert them to FLAC.
It would be great if this can get the new Project 64 recompiler and all that jazz. I especially want to hear if there IS something wrong with the pitch of the Rareware games that were mentioned (DK64) and if that changes with an update.
I know for sure Ocarina of Time is off compared to the official OST releases, though really you should listen to those for that anyway because the OST sounds like it uses higher fidelity versions of the same samples.
edit: http://help.foobar2000.org/problem/2e329a5666a483c2197fff811c51a1ab When I last tried to play a Mario Party track.
Not touching recompilers, I need accurate interpreters only. Unless someone wants to port recompilers to x86_64 and ARM, as well as any other platforms that may deserve this library.
oddMLan at 10:49 PM EDT on August 30, 2014 The Donkey Kong 64 USF rip from the official repository seems to be from the PAL version of the game; the tracks sound a couple of cents lower compared to the NTSC version of the game. Only the PJ64 1.6 core suffers from this bug, which is the one that the 64th note uses. Project64 2.x has fixed the bug, so the PAL and NTSC version of the game sound exactly the same. -My fault :P Can't remember the reason why...i think it was the only rom of it at the time, and didn't bother (or care) to use a NTSC version.
Kirishima at 12:02 PM EDT on September 5, 2014 Well, if someone does an update it will hopefully fix Mario Party which doesn't work with the current plugin. ? It works perfectly fine for me? Using what settings?
kode54 at 6:45 PM EDT on September 30, 2014 Not touching recompilers, I need accurate interpreters only. Agree! I ported the Project64 recompiler to x86_64 (very badly at that). Re-doing that for multiple platforms (and one such as ARM) will be a major pain in the ass. Fast interpreter+hle all the way ☺
Mario Party works fine with foobar, but not with the current winamp(or plugin).
Winamp Plugin Update by TwilightOne at 6:31 PM EDT on October 21, 2014
Hello Josh!
First thank you for your work! My problem is with the newest version of the plugin... I use MediaMonkey (For library options...)which is compatible with Winamp plugins but the "latest" beta version of 64th note for Winamp will not work on my system.
Thank you very much, I hope you can give me a positive answer!
The plugin, when it tries to load the INI file, it sends a 'WM_WA_IPC' call which MediaMonkey doesn't support, gets nothing back and dies.
I've attempted to fix this, by reverting it to the old Winamp 2.x behavior if the message returns nothing. Also, I had signifcant difficulty getting it compiled under Visual Studio 2013, so I can't 100% guarantee nothings broken. :) Get it here
the ini API message was added in v2.9 so it's technically a 2.x API... and i'm sure the in_usf mods i provided showed how to use it correctly for the different Winamp versions.
Now it needs something to get Banjo Tooie working, and I think it may be the R4300i interpreter's fault for messing something up. The failsafe I added to the main emulation loop prevents it from livelocking completely.
The original assumption of the library in my current design was that the DMA would always produce a stream of samples, and it runs until the client supplied buffer is filled completely, buffering up any remainder until the next client call.
Unfortunately, rips which are broken in the way of the BT rip don't actually reach any DMA streaming state, so they run whatever code for ages on end. So I added a simple check that keeps a count of how many R4300i instructions have executed since the last DMA block was transferred, and if that hits some high count, it aborts with an error message. It doesn't break any games that I've tested, at least none that weren't already broken.
At least now, with that IIR filter in the HLE code, HLE is prime for most regular use cases. That one RSP breakage should still be fixed, since the RSP code I borrowed could use that fix upstream for full system emulation. (If it wasn't mentioned here, I don't recall where it was, I'll have to dig around.)
EDIT: I've updated lazyusf in my repository with a quick fix for TLB accesses outside the range of N64MEM, so that they now do some generic open bus thing. This stops Harvest Moon 64 from crashing.