editor-on-fire
editor-on-fire copied to clipboard
raynebc
Support Feedback export
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
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 [email protected] on 5 Aug 2010 at 12:24
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
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 [email protected] on 6 Aug 2010 at 6:22
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
Issue 151 has been merged into this issue.
Original comment by raynebc on 3 Oct 2010 at 6:09
On hold until native MIDI timing is implemented.
Original comment by raynebc on 22 Mar 2011 at 12:20
- Changed state: On_Hold
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
Commit 2259a78 added special MIDI export logic that maps grid snap positions to delta times using integer math. This approach should theoretically avoid floating point related math/rounding errors, and could probably be used for a Feedback export function.
