Support Feedback export

[GoogleCodeExporter]

This has been on my to-do list for a little while, but there was a thread that 
highlighted where being forced to use just either Feedback or EOF is 
inconvenient for the user:
http://www.fretsonfire.net/forums/viewtopic.php?f=3&t=48029&start=0

If EOF supported the ability to export to .chart format (or maybe even saves a 
.chart file when the MIDI is created), it would make it easier for users to 
work on the same file between different editors.

The timing conversion between ticks and millis will still be an issue, but this 
will probably be taken care of in the future if ticks are stored with the 
note's millisecond position.  Perhaps something like this:

struct Notepos
{
    unsigned long ticks;
    double millis;
};

Based on which format the opened file was, one of the two timings can be 
dominant.  If a Feedback or MIDI was imported, ticks can be the dominant timing 
method, and any anchor/note changes will trigger the millisecond variable to be 
recreated.  If an EOF project file was imported, the current logic can be kept, 
since realtime is already the timing method being used, and the ticks will be 
determined when the project is saved.

That's a bit complex to implement, so perhaps the most important thing is to 
prevent timing deviation for anchors when a Feedback file is imported and 
re-exported.  Perhaps EOF's anchors can maintain their original tick timing (or 
a high precision floating point realtime), so that when the .chart file is 
exported, there's a high reliability of the anchor positions retaining the tick 
times the original imported chart had.

Original issue reported on code.google.com by raynebc on 8 Jul 2010 at 11:13

[GoogleCodeExporter]

This will not be a problem once the new MIDI-based timing method is 
implemented. Everything will use MIDI ticks dominantly with millisecond-based 
timing only used to render the notes on-screen. We will not need a high 
precision real time value because the smallest time granularity EOF can display 
on screen is 2ms.

Original comment by xander4j...@yahoo.com on 5 Aug 2010 at 12:24

[GoogleCodeExporter]

Ultimately, I think using absolute delta times will work out best.  Perhaps 
this should wait until after the EOF 1.66 stable release, as there have been a 
good number of fixes since r212.

Original comment by raynebc on 6 Aug 2010 at 6:11

[GoogleCodeExporter]

Yes, we should definitely do a release before switching to the new timing 
system. I was thinking absolute "delta" times as well. Basically like .chart 
format. Calculating relative delta times for MIDI export would just be a matter 
of simple subtraction.

Original comment by xander4j...@yahoo.com on 6 Aug 2010 at 6:22

[GoogleCodeExporter]

That's pretty much how MIDI export is currently working:  The logic I 
implemented converts realtime to absolute delta time, and I subtract from the 
previous absolute delta time to get the relative delta time for each event.

Original comment by raynebc on 6 Aug 2010 at 6:40

[GoogleCodeExporter]

Issue 151 has been merged into this issue.

Original comment by raynebc on 3 Oct 2010 at 6:09

[GoogleCodeExporter]

On hold until native MIDI timing is implemented.

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

• Changed state: On_Hold

[GoogleCodeExporter]

Since EOF now has logic to keep notes grid snapped at all times, the logic to 
identify the grid snap position a note is at could be leveraged to export an 
accurately timed .chart file.  All notes not on a grid snap would have to be 
rounded to the nearest delta tick, but that's to be expected.

Original comment by raynebc on 14 Jun 2015 at 2:13

• Changed state: Accepted