carlito913 / editor-on-fire

Automatically exported from code.google.com/p/editor-on-fire
Other
0 stars 0 forks source link

MIDI export TS desync #244

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
As reported here:
http://www.fretsonfire.net/forums/viewtopic.php?f=11&t=50698&p=581197#p581190

A RB3 MIDI experiences desync starting with the note at 1:02.  This part of the 
chart has many gratuitous TS changes, so since FoFLC gets the same timestamps 
that Reaper does for this note, it's probably just a special case that needs to 
be added.

Original issue reported on code.google.com by raynebc on 10 Mar 2011 at 4:14

GoogleCodeExporter commented 8 years ago
It is confirmed to be a tempo map issue.  EOF marks beat 100 as being at 
60200ms when it should be 62474ms (as per FoFLC's logging).

Original comment by raynebc on 10 Mar 2011 at 6:45

GoogleCodeExporter commented 8 years ago
r722 probably resolves the problem seen by importing this MIDI.  After the 
change, the waveform shows that all beat markers appear to be accurate, I'll 
examine the chart some more before closing this issue.

Original comment by raynebc on 10 Mar 2011 at 10:43

GoogleCodeExporter commented 8 years ago
The guitar notes for the entire 9:50 long chart appear to import correctly 
synced.  I'm going to consider this fixed.

Original comment by raynebc on 11 Mar 2011 at 1:42

GoogleCodeExporter commented 8 years ago
Even though the tempo map imports correctly now, it looks like the note timings 
are also inaccurate during the part of the chart that is #/8 TS.  It seems that 
the TS logic will probably have to be removed or altered until it's accurate 
for import and eventually to the point where it exports correctly.

Original comment by raynebc on 11 Mar 2011 at 7:23

GoogleCodeExporter commented 8 years ago
The remaining TS import issues are fixed in r723.  Both the tempo map and the 
notes themselves import with correct timing even when the #/8 time signatures 
are encountered.  Since #/4 and #/8 are both accurate, it's likely that it's 
accurate for other time signatures as well.

Now, the exported chart still exhibits some problems around where the #/8 time 
signatures start.

Original comment by raynebc on 20 Mar 2011 at 12:46

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r724.

Original comment by raynebc on 20 Mar 2011 at 1:01