midi parsing errors?

[kritanaz]

I took a song with the new player and the old one, and the new one seems to jumble the notes together from what I can notice, this happens with a lot of things I have made

also https://puu.sh/AuUyf.webm for a video/audio example

[isalin]

Could you check if this works? And if not, could you send me the magic dance file?

TBbard_v1.7b.zip

[kritanaz]

it seems to have fixed the note jumbling issue, as wait times seem to be correct however now there seems to a problem with notes related to them being held/repeated, I tested it with a song with less variety?

upon loading the program this song parsed like this (notice the release being used for notes that are supposed to be there, but aren't)

but then another time it was done I managed to get it like this

which is in fact, correct

I tested on another song as well, which had the same error.

from what I have gathered it seems you made a new code the (h) but the (release) code is still trying to be used, and is overwriting the notes

https://puu.sh/AvajF.mid https://my.mixtape.moe/chtsyg.webm here is a copy of the midi file for this specific one, and I have a webm to compare the sound with the 1.6 player if you're trying to see if it's correct.

hopefully this gives you a lot of context to go on

[isalin]

Oh, I think I see what was wrong. If a note and a "release" happened at the same timestamp it would only process whichever one was encoded first. I've changed it to always prioritize notes over releases.

Could you check if this works for you?

TBbard_v1.7c.zip

[kritanaz]

seems everything is working as intended now, I can't find any faults with it so far even with very fast playing

pleasure to work with you and help you out!

edit: actually, there is one thing i noticed, if for example you have the same note, ex D, D, D, rather than playing them all it will play one then hold for the duration of all 3. Not sure how to fix with that but other than that it's pretty solid for right now regardless, problem is solved if you turn off hold

[isalin]

Ah, that's probably because of input limitations in ffxiv. It seems to sample your input once every frame (it's why TBbard asks for your min fps).

It probably doesn't have time to notice that the key has been released and pushed down again and interprets it as the key being held down the whole time. I've uploaded a fixed version in the releases section.

Oh, and thank you for the help!

[hyskylord]

The 1.7 and 1.7d version sometimes make parse like this, like it double click every note parsed. Didn't face this problem in 1.7a for the same midi file however.

[isalin]

Could you link me the midi file?

[hyskylord]

TBBardParse.zip Sorry that I recalled the false version, when I tried it again the version it worked is 1.7b, and other seems to be broken. Hopefully it will help.

[isalin]

Could you check that this fixes it?

TBbard_v1.7e.zip

[hyskylord]

TBBARD1.7APARSE.txt TBBARD1.7BPARSE.txt TBBARD1.7Dparse.txt

Made a full test about this midi file, and something seems strange to me. For the parsed TXT file, the 1.7b gave the same result as 1.7e, and 1.7a is nearly the same as 1.7d. However, the 1.7a doesn't appear to have the double click issues though it has a lot of w0 and w1 notes, while 1.7d does.(Sorry again for misleading above, but the version worked for me is exactly 1.7a but not 1.7b). So I suppose it's because of some changing in the playing part but not the parsing part that cause my issue.

And as for the final result, playing 1.7a parse file in 1.7a.exe still seems best to me, even though it still have a little uncoordinated notes. and I tried playing 1.7d parse file in 1.7a.exe, and find that it's not as good as 1.7a files in the slight different part. The rhythm in 1.7b and 1.7e files are, however, nearly broken for me though it doesn't have w0 and w1 notes and double click. Playing in 1.7d will have strange double click problem and also be broken.

[hyskylord]

I see where the problem is, if the raw parse is like A w100 A w1 B w100 B Then 1.7b and 1.7e would try to make it into A w100 A w101 B which double the duration of note A. Tried to make a fix of this in the pull request. However there are still some issue about the tick, for the file I send above, it just divided a "w153" into "w152" and "w1", but for this file: To_Loves_End.zip TBbard divided a "w500" into "w473"+"w26", and a "w1000" into "w948"+"w51", which cannot be solved by my fix since I just set the filter into <10. Noticed that this is because the parser split a single note into two notes because of the change in velocity inside the note, while FFXIV doesn't need that.

[isalin]

Oh, I see. That file is actually encoded a bit differently than what I've seen before.

Most files will end a note with a "Note off" event that essentially silences the note. TBbard uses this to parse the "Release" events.

The file you linked instead uses a second "Note on" event, but with 0 velocity. That kind of alters the note to suddenly be a note that finishes playing immediately. It's kind of clever and not something I'd considered before. This is also why notes were repeating in that file (and possibly others).

I think I also fixed a small pacing bug.

Could you double check that this one works?

TBbard_v1.7f.zip

[hyskylord]

yeah I also found out all the strange additional "w1" notes i faced before is because of the velocity 0 settings. But it seems the duration problem is still there for some reason.

[isalin]

Your fix worked great!

I'm not sure I understand what you mean by duration problem?

[hyskylord]

I mean I just did a quick test on 1.7f and found that some notes had strange duration and some even been out of tune. Nvm if you didn't use that anymore, since the master branch works pretty well for me now.