- Phase Shift -

[kamakazikilla]

I can't think of any reason it wouldn't work. If you make a song with 12th notes and Phase Shift won't play those as HOPOs, please send me and/or thekiwimaddog a copy of the chart files and we'll look into it.

okay...

here you go...

http://www.mediafire.com/?kpda13jbir537es

that's the chart in question... literally the entire song except for a couple in the beginning, and the ending is in 12 note snap.....

[raynebc]

Looking at the MIDI, the notes appear to be being written at intervals of 160 deltas (except for the occasional one written at an interval of 159 deltas due to rounding, which should also trigger as HOPO), which is 1/3 beat based on the time division being used, which is correct. This may be a Phase Shift issue if they won't play as HOPOs but are supposed to.

[kamakazikilla]

Looking at the MIDI, the notes appear to be being written at intervals of 160 deltas (except for the occasional one written at an interval of 159 deltas due to rounding, which should also trigger as HOPO), which is 1/3 beat based on the time division being used, which is correct. This may be a Phase Shift issue if they won't play as HOPOs but are supposed to.

so basically this isn't related to EOF having an issue and i did everything correctly to make HOPOs occur? hmm, then i guess i'll wait for the Phase Shift side of the story to see if there's any reason for this......

[thekiwimaddog]

Looking at the MIDI, the notes appear to be being written at intervals of 160 deltas (except for the occasional one written at an interval of 159 deltas due to rounding, which should also trigger as HOPO), which is 1/3 beat based on the time division being used, which is correct. This may be a Phase Shift issue if they won't play as HOPOs but are supposed to.

so basically this isn't related to EOF having an issue and i did everything correctly to make HOPOs occur? hmm, then i guess i'll wait for the Phase Shift side of the story to see if there's any reason for this......

There are still some notes in this MIDI that are more than 1 Tick longer than the HOPO frequency. I've set the tolerance to 3 Ticks and that seems to have fixed it and I'll leave it like this for now.

David

[kamakazikilla]

Looking at the MIDI, the notes appear to be being written at intervals of 160 deltas (except for the occasional one written at an interval of 159 deltas due to rounding, which should also trigger as HOPO), which is 1/3 beat based on the time division being used, which is correct. This may be a Phase Shift issue if they won't play as HOPOs but are supposed to.

so basically this isn't related to EOF having an issue and i did everything correctly to make HOPOs occur? hmm, then i guess i'll wait for the Phase Shift side of the story to see if there's any reason for this......

There are still some notes in this MIDI that are more than 1 Tick longer than the HOPO frequency. I've set the tolerance to 3 Ticks and that seems to have fixed it and I'll leave it like this for now.

David

alright =] sounds good to me.... these seem to be pretty small units of measurement, so i doubt it will have any real negative effects if you do that.... although if you had the same problem with the 8th notes, there should be some kind of fix for EOF if there's anything that can be done to make it more percise, or the same would need to be done for 8th notes... (although they probably fluctuate more because it's a larger distance between snapped notes??) so that kind of tolerance might be too big to mess with... idk...... just a thought... hopefully i'm being more helpful than i am annoying!!

[raynebc]

If you can describe which notes those are, please let me know. I looked at the first several, but they were all within 160 deltas of the previous gem's note off event, which should still allow them to be HOPO. Having them all within 160 deltas of the previous gems' note on is not feasible due to math rounding errors. If Phase Shift is comparing one gem's note on with the previous gem's note on to see if it's close enough for HOPO, it would probably be better to compare it to the previous gem's note off position instead to prevent this kind of limitation. It is not reasonably possible to avoid this kind of rounding error because of the large difference in millisecond timing versus delta timing. For this reason, in the future, EOF will natively use tick based timing (like MIDI files) so this won't be a problem for new charts, but this HOPO detection (comparing "note on" to "note on" timings) may be problematic for existing EOF/Feedback charts.

[kamakazikilla]

If you can describe which notes those are, please let me know. I looked at the first several, but they were all within 160 deltas of the previous gem's note off event, which should still allow them to be HOPO. Having them all within 160 deltas of the previous gems' note on is not feasible due to math rounding errors. If Phase Shift is comparing one gem's note on with the previous gem's note on to see if it's close enough for HOPO, it would probably be better to compare it to the previous gem's note off position instead to prevent this kind of limitation. It is not reasonably possible to avoid this kind of rounding error because of the large difference in millisecond timing versus delta timing. For this reason, in the future, EOF will natively use tick based timing (like MIDI files) so this won't be a problem for new charts, but this HOPO detection (comparing "note on" to "note on" timings) may be problematic for existing EOF/Feedback charts.

hmm, alrighty... on a sidenote, if i loaded up an old chart onto the newer version of EOF (whenever it comes out) and i clicked the resnap feature, would this fix it?? or would i completely need to re-chart the song??

[raynebc]

With the current logic in EOF, resnap may help, but for reasons I explained in the previous post, we cannot guarantee that a rounding loss of 1 delta tick wouldn't occur. If two notes' "note on" events are 161 delta ticks apart, PS would have to allow it (which is what thekiwimaddog indicated regarding the tolerance) to be a HOPO because it's technically further apart than two 12th notes should be. However, if PS will compare the distance between the end of one note with the start of the next, it may resolve this problem. I don't know how Phase Shift's HOPO detection works though, since it's closed source.

[kamakazikilla]

With the current logic in EOF, resnap may help, but for reasons I explained in the previous post, we cannot guarantee that a rounding loss of 1 delta tick wouldn't occur. If two notes' "note on" events are 161 delta ticks apart, PS would have to allow it (which is what thekiwimaddog indicated regarding the tolerance) to be a HOPO because it's technically further apart than two 12th notes should be. However, if PS will compare the distance between the end of one note with the start of the next, it may resolve this problem. I don't know how Phase Shift's HOPO detection works though, since it's closed source.

alright... thanks both of you for: 1.being so darn smart, 2.doing your best to solve the problems, 3.putting all this into a language i pretty much understand... haha, i'll keep everyone posted on anything else i find, especially after the next version with the fixes comes out (which will probably contain a bunch more "thank you's" and the like)

[PiXeLaDo]

Suddenly, I tested:

The first hopos are all 12th@110BPM (as if BPM matters lol) and it's made with FeedBack, so I guess the problem is on your side *cough*EOF*cough*
Hope it gets solved soon.

EDIT: the youtube tag was not showing up so: http://www.youtube.com/watch?v=QBtJtKSyPts

[raynebc]

Feedback does not store anything in milliseconds, so as I said, it's a limitation due to timing conversion. We'll wait to hear from thekiwimaddog to see if he is able to confirm how PS detects HOPOs. There's nothing I can do in the mean time.

[thekiwimaddog]

Feedback does not store anything in milliseconds, so as I said, it's a limitation due to timing conversion. We'll wait to hear from thekiwimaddog to see if he is able to confirm how PS detects HOPOs. There's nothing I can do in the mean time.

PS does go by Note On to Note On for HOPO detection but I'm pretty sure this is how it's supposed to be. Many songs have tails which finish just before the next note that are not supposed to be HOPO. This also has to be true otherwise Extended Sustain HOPOs wouldn't work.
Does this have something to do with why any non sustained note in EOF has it's duration set to 1??
I may be wrong about this and if so I'll make the change.

Give me a min and I'll track down the problem notes in that MIDI.

Thanks
David

-- Edit: Tue Nov 09, 2010 10:13 am --

OK here is an example in that MIDI:

Code: Select all

ID:241 Delta Time:158 NOTE ON Channel:1 Data 1:97
ID:242 Delta Time:1 NOTE OFF Channel:1 Data 1:97
ID:243 Delta Time:162 NOTE ON Channel:1 Data 1:98
ID:244 Delta Time:479 NOTE OFF Channel:1 Data 1:98


As you can see the distance between the 2 notes is 163 Ticks, even if I was calculating from NOTE Off to Note On it would still be 162 Ticks.

Thanks
David

[raynebc]

You're right about that, that's out of bounds. I resnapped the chart at 1/48 grid snap and I think it fixed the note placements. Here's my converter's debug output for those notes now:

Delta file pos=0x5A4 Deltas=159 Real time=19061.218667ms Delta time=23840 Adj. real time=19061.218667ms Event file pos=0x5A6 Event: Note on (Channel=0): Note #=97, Velocity=100
Delta file pos=0x5A9 Deltas=1 Real time=19062.007075ms Delta time=23841 Adj. real time=19062.007075ms Event file pos=0x5AA Event: Note off (Channel=0): Note #=97, Velocity=100
Delta file pos=0x5AD Deltas=159 Real time=19187.364000ms Delta time=24000 Adj. real time=19187.364000ms Event file pos=0x5AF Event: Note on (Channel=0): Note #=98, Velocity=100
Delta file pos=0x5B2 Deltas=479 Real time=19565.011592ms Delta time=24479 Adj. real time=19565.011592ms Event file pos=0x5B4 Event: Note off (Channel=0): Note #=98, Velocity=100

Those note on events are 160 deltas apart exactly, so it looks like EOF's save routine is fine. It's just that moving anchors after notes are placed can cause grid snapped notes to lose sync (since notes will adjust relative to the beat marker positions and not grid snap positions, causing rounding errors of 1ms in either direction to be possible, which is just long enough to cause this and prevent a note from being a HOPO note. That's OK though, and what "resnap" is for. So for now, anybody that needs HOPOs to be reliable should make sure to resnap. 1/48 is good for most cases, but I believe you could use any custom grid snap you wanted, such as 1/64. If you have a sloppy solo that needs to stay un-grid-snapped, you'll want to make sure those are not selected when you perform the resnap. If you'd be willing to verify the notes register as HOPOs, here is the resnapped MIDI (rename to notes.mid after you back up the old one somewhere):
http://www.sendspace.com/file/3lzfuj

[kamakazikilla]

hmm, well for the sake of actually seeing this work, i'll just pop up EOF and resnap myself.. i'll get back to you guys in a sec.

[thekiwimaddog]

You're right about that, that's out of bounds. I resnapped the chart at 1/48 grid snap and I think it fixed the note placements. Here's my converter's debug output for those notes now:

Delta file pos=0x5A4 Deltas=159 Real time=19061.218667ms Delta time=23840 Adj. real time=19061.218667ms Event file pos=0x5A6 Event: Note on (Channel=0): Note #=97, Velocity=100
Delta file pos=0x5A9 Deltas=1 Real time=19062.007075ms Delta time=23841 Adj. real time=19062.007075ms Event file pos=0x5AA Event: Note off (Channel=0): Note #=97, Velocity=100
Delta file pos=0x5AD Deltas=159 Real time=19187.364000ms Delta time=24000 Adj. real time=19187.364000ms Event file pos=0x5AF Event: Note on (Channel=0): Note #=98, Velocity=100
Delta file pos=0x5B2 Deltas=479 Real time=19565.011592ms Delta time=24479 Adj. real time=19565.011592ms Event file pos=0x5B4 Event: Note off (Channel=0): Note #=98, Velocity=100

Those note on events are 160 deltas apart exactly, so it looks like EOF's save routine is fine. It's just that moving anchors after notes are placed can cause grid snapped notes to lose sync (since notes will adjust relative to the beat marker positions and not grid snap positions, causing rounding errors of 1ms in either direction to be possible, which is just long enough to cause this and prevent a note from being a HOPO note. That's OK though, and what "resnap" is for. So for now, anybody that needs HOPOs to be reliable should make sure to resnap. 1/48 is good for most cases, but I believe you could use any custom grid snap you wanted, such as 1/64. If you have a sloppy solo that needs to stay un-grid-snapped, you'll want to make sure those are not selected when you perform the resnap. If you'd be willing to verify the notes register as HOPOs, here is the resnapped MIDI (rename to notes.mid after you back up the old one somewhere):
http://www.sendspace.com/file/3lzfuj

This MIDI seems perfect now.
I'll leave a Tolerance of 3 Ticks in for now as it shouldn't do any harm.
Would that be the highest I'd need to account for?

Thanks
David