Closed sezero closed 9 years ago
After testing and testing I can hear what you are complaining about.
However here is the issue ...
1) People don't want notes to end abruptly. 2) People don't want a small amount of time added to the end to allow notes to end smoothly. 3) People don't want final notes ending smoothly at the start of the next loop.
So only the only solutions are 1) end notes abruptly at end of song 2) allow for space at end for final notes to decay 3) allow final notes to decay smoothly at the start of subsequent loops
Please choose which solution you would like as there are no other solutions.
At the moment the lib uses solution 2 normally and solution 3 when looping.
On 3/15/15, chrisisonwildcode notifications@github.com wrote:
After testing and testing I can hear what you are complaining about.
Just to make sure we are at the same page:
Are you saying that your current looping code is supposed to do this?
I'm not having it "repeat" .. what I have happen is the release for the end overlaps the start ...
If you are using WM_MO_LOOP ... make sure you aren't rewinding the midi. The lib does it itself.
I am occasionally having issues where the check for the loop setting is getting bypassed and I am looking into this at the moment.
@sezero ahha!! found the issue (after I fixed an unrelated bug with WildMidi_FastSeek) ... don't worry a fix is on its way ...
@sezero please grab latest master and test. Don't be surprised if there is typo's, its 12:33am and I've been up since 4am :)
Report all issues and I shall deal with them as I get to them.
Get some sleep first... ;)
Commit 141deb1 seems to have fixed it. Closing.
With WM_MO_LOOP, notes from last event are left at the start upon library rewinding the song. Noticeable with meso.mid of hexen2. (File sent to Chris personal email.)