MSU1 audio resume [higan beta]

Download + Usage Instructions:
http://board.byuu.org/phpbb3/viewtopic.php?f=4&t=735

This adds the MSU1 audio resume discussed from this thread:
viewtopic.php?f=12&t=11039

The API is detailed in this post:
viewtopic.php?f=12&t=11039&start=30

Would appreciate if any MSU1 hackers could give this a try and see how it goes. I don't have any code handy on my dev box to test this out. The API is still experimental, so please feel free to report any grievances with how it works. Speak now, or forever hold your peace, because v096 will finalize the API forever.

I imagine that right now, this'll only be useful for DarkShock's Chrono Trigger work.

Awesome, thanks! I'll definitely try this out some time next week.

Here's a demo of this, source is included. (Be warned -- this is based on some very old MSU1 audio test of mine, which in turn was based upon an early beta PowerPak firmware. )




Download:
http://manuloewe.de/snestuff/msu1-with-resume.7z

Usage:
Just copy the msu1.sfc folder from the archive to your higan library.


Some feedback for @byuu:
Apparently, icarus ignores *.msu files upon import, which is odd. Also, I can't seem to adjust icarus' import target folder, which seems to be hardcoded to %USERPROFILE%\Emulation\Library (which it isn't on my computer, though).

Lastly, having to set the resume flag when stopping the current track is rather unintuitive, IMHO. From a developer's point of view, I'd expect it to be something like this: I set the resume flag whenever I start playing track #1. Then, when I start¹ track #2, I make sure the resume flag is clear (unless I want track #2 to resume after track #3, in which case the resume position of track #1 would inevitably be lost), so that when I switch back¹ to track #1, MSU1 fetches the resume position of track #1.

Apart from that, the new resume feature is totally awesome! Thanks again!

¹ i.e., not clearing the play flag every time I switch to another track ...

Cool, thanks for testing it out!

> Apparently, icarus ignores *.msu files upon import, which is odd

icarus doesn't yet support MSU1. It will in the near future.

> Also, I can't seem to adjust icarus' import target folder, which seems to be hardcoded to %USERPROFILE%\Emulation\Library

Go to %appdata%\icarus\settings.bml and you can change the path there. I need to add a GUI configuration panel for this to icarus still.

> I set the resume flag whenever I start playing track #1

Hmm ... yeah, I can make it work that way. That would also avoid the -need- to stop the track via $2007 write at the end (the $2005 write would have the same effect.)

In this way, it can be called the "resume" flag again instead of the "save" flag.

This will be different from the earliest method in that this flag only says "save the offset when the track ends", rather than "immediately seek to the last saved offset", the latter of which would force a sync event.

Okay, let me think about it for a bit. If I don't see any down sides, I'll change this in the next WIP.

See, that's what I love you for, mate.

Please take all the time you need to consider. All that counts is that your MSU1 implementation benefits from my input (or anyone's, for that matter).

So, bad news ...

I've been thinking about this, and came up with some downsides I can't work past.

Foremost, is the start of a new song isn't the best time to know if you'll want to resume. Let's take Chrono Trigger as the example. You go from the world map into an area with resumable music (a place where you can get into battles.) But at the start of the song, you don't know whether the player will walk back to the town, or enter a fight. However, you *do* know that when you go to stop the resumable music, because you can see whether the next track is battle music or town music.

The second issue is how to handle subsequent $2007 writes. This is also a way to pause music, so what would it mean if the user paused the music with a different value? Having a one-time latch would require extra state and be very awkward, so the only realistic method would be to always update the resume bit on all $2007 writes (when the audio port isn't busy, of course.)

Now certainly, we could allow the value to be updated whenever. But the added flexibility comes at added complexity. You're still gonna want to make sure the final $2007 write has the bit set, so we might as well avoid having to track it unless the track isn't actually playing. And not having to cache the bit during playback means we don't have to do another test once the track actually stops to cache final playback sample position.

So it is a nice idea, but I think the current method will be a bit smoother, even if a bit unintuitive.

Really, I think anything we come up with will be slightly hacky out of necessity. What was really needed was for $2005.d7 to be the resume bit (and the implementation could automatically track the last N song stop positions.) But we can't maintain backward compatibility with that, so anything we come up with is going to be a bit hacky now :/

Still, open to more suggestions of course.

Hey byuu, I can't get any SFC games to work with your higan beta build. The only game that boot was Mega Man X but froze instantly. Famicom works no problems, I didn't try other consoles but obviously, I need the SFC plugin to work in order to test my CT hack with it

You need to copy the beta EXEs into the v095 official release folder.

Specifically, the EXEs need to be next to the "Super Famicom.sys/", etc folders to work.

Just tested with Chrono Trigger and Super Metroid, works great ! I only had to do one change to my resume experiment in Chrono Trigger: removing the line that set the resume flag when playing the resumed track.

Hey, byuu,

wow, this is really well thought out. I can only agree to stick with your current implementation.

Thank you for your time and effort!
Ramsis

> Just tested with Chrono Trigger and Super Metroid, works great ! I only had to do one change to my resume experiment in Chrono Trigger: removing the line that set the resume flag when playing the resumed track.

Neat! Gotta love success on first try :D

Shouldn't need to write a 0 to the resume bit when the play bit is set to 1. But it's probably a good idea all the same.

> Thank you for your time and effort!

Sure, and thank you for the feedback!

Seems we're in agreement, so let's go ahead and call this mostly final.

v096 shouldn't take nearly as long as v095 did. Just need to add video shaders back, and get all my work moved over to my new server PC build. The latter's going to take a while as I want to redo all of my setup and storage.