Add native time signature support

[GoogleCodeExporter]

I'd be willing to take a stab at this.  Are there any charts submitted with a 
MIDI that has time signatures?

Original issue reported on code.google.com by raynebc on 18 Aug 2010 at 12:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

In theory, the tempo applies to all instruments, but each instrument is 
independent in its use of a time signature.  The formula we'd been using to 
convert deltas to realtime assumed that one quarter note was the same as one 
beat.  This is not the case if the denominator of the time signature isn't 4.  
For example:  If you consider a tempo change of 500000 MPQN and a TS of 3/4, 
the ratio of quarter notes to beats is 1:1, and the number of quarter notes per 
minute is the same as the number of beats per minute.  However, if the TS is 
changed to 3/8, one quarter note is now 2 beats.  Although the tempo hasn't 
changed, the beat plays twice as long, sounding as if the tempo had been 
halved.  This means that the note has to play for more ticks than it would with 
the 3/4 TS.

The conversion formula needs to be scaled based on the ratio of the current 
time signature's denominator versus 4 (the denominator where one quarternote is 
one beat), changing the formula to:

scale = TS denominator / 4
deltas / (time division) * (60000.0 / BPM) * scale

The updated formula simplifies to:
deltas / (time division) * (15000.0 / BPM) * (TS denominator)

Original comment by raynebc on 19 Aug 2010 at 1:52

[GoogleCodeExporter]

This would also require new time signature data to be stored in the beat 
markers so that eof_calculate_beats() and the like could properly map out the 
beats, taking the new information into consideration.

Original comment by xander4j...@yahoo.com on 19 Aug 2010 at 12:38

[GoogleCodeExporter]

I came to the conclusion that we'd actually have to store a list of TS changes 
for each MIDI track.  As unlikely as it would be, I believe it's legal for each 
MIDI track to have a different time signature.  Some of the more involved 
charters may end up doing this.

Once all this TS logic is implemented, we could probably expand EOF to allow 
any valid TS to be applied by the user.  At this point, making the default TS 
for all tracks to be 4/4 would probably be a good idea.

Original comment by raynebc on 19 Aug 2010 at 2:27

[GoogleCodeExporter]

r307 and r308 make progress on this issue.  During import, all time signatures 
are stored and used in the delta time->realtime conversion for the other MIDI 
events.  Although this isn't tested, hopefully it will allow MIDIs that use 
something besides #/4 TS to import correctly.  EOF's current time signature 
storing will likely need to be changed, as implementing a wide range of 
signatures would require too many different flags.  My recommendation would be 
to have the EOF_TRACK structure store a EOF_IMPORT_MIDI_TS_LIST pointer.

Original comment by raynebc on 20 Aug 2010 at 8:48

• Changed state: Started

[GoogleCodeExporter]

evilbobthebob submitted a chart that has tons of Time Signatures:
http://www.sendspace.com/file/y6ie7w

It was created as a Feedback chart and converted to MIDI.  He indicates that 
the .chart file imports just fine, but the MIDI imports with desync.

The way MIDI import works now, certain kinds of MIDI events are mixed into a 
single array without noting which track they came from.  This will make it 
impossible to properly implement time signatures, as each track has its own 
time signatures.  The easiest fix I can think of would be for the events to 
store the track number they came from.  If you agree that is a suitable fix, 
EOF can be modified accordingly.  Until this is corrected, MIDI import is 
broken.

Original comment by raynebc on 22 Aug 2010 at 12:09

[GoogleCodeExporter]

So certain MIDI events are timed incorrectly because of not taking the TS into 
account for the track they came from? If that's the case I don't see why we 
wouldn't want to store the track number as well so everything can be timed 
correctly.

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

[GoogleCodeExporter]

This should be as simple as having the eof_midi_import_add... functions store 
the MIDI track number.

Original comment by raynebc on 22 Aug 2010 at 2:14

[GoogleCodeExporter]

Based on my findings so far, it may be common for a MIDI file to just have Time 
Signature changes in Track 0 and none in any other track.  Perhaps the logic 
could be adaptive so that if Track 0 is the only one to have TS changes, its 
changes are used for all tracks.  Otherwise, each track maintains its own TS 
changes.

Original comment by raynebc on 23 Aug 2010 at 6:36

[GoogleCodeExporter]

r320 changes the import behavior to store the track number for MIDI events.  
This should allow correct event timing conversions, but EOF's current logic for 
calculating beat marker positions may be incompatible with the concept of each 
track having conflicting time signatures.  If my suspicions are correct, EOF 
would ultimately have to recalculate the beat marker timestamps each time the 
active track was changed, as well as determine the measure markers, etc.

There will probably also need to be more logic to allow for track 0's TS 
changes to apply to the entire MIDI if no other tracks have TS changes.

Original comment by raynebc on 23 Aug 2010 at 5:44

[GoogleCodeExporter]

r322 adds the logic to apply TS changes from track 0 to all other tracks if it 
is the only track containing TS changes.

Original comment by raynebc on 23 Aug 2010 at 7:36

[GoogleCodeExporter]

Adding support for different TS changes for each track may be overkill.  Even 
though it would add more functionality, it would complicate things.  If you 
prefer, during the editing process, EOF could maintain just a single list of TS 
changes, in the way that a single list of anchors is maintained.  We'd just 
need to figure out what to do with an imported MIDI that had different changes 
in each track.

Original comment by raynebc on 24 Aug 2010 at 5:02

[GoogleCodeExporter]

After this is completed, time signatures for Feedback import can be handled.  
According to the information I compiled, Feedback only supports #/4 time 
signatures.

Original comment by raynebc on 28 Aug 2010 at 4:21

[GoogleCodeExporter]

r332's new logic will also need to be updated with whatever Time Signature 
logic is ultimately determined to be correct.

Original comment by raynebc on 31 Aug 2010 at 10:29

[GoogleCodeExporter]

I think it's safe to assume that TS events have to occur on beat lines?  If 
that's the case, then each track could store a simplified TS list.  This can be 
either of the following:

A list of which beats are TS changes, and the numerator and denominator for 
each change.  This is more memory efficient.

A numerator and denominator for each beat marker.  This would allow a beat's 
time signature to be determined more quickly.

Once the storage of TS changes is updated, we can determine the next needed 
change.

Original comment by raynebc on 8 Sep 2010 at 7:22

[GoogleCodeExporter]

Original comment by raynebc on 3 Oct 2010 at 9:44

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

Since the research has gone stale, I created a thread asking for information:
http://www.fretsonfire.net/forums/viewtopic.php?f=3&t=49482

Original comment by raynebc on 8 Oct 2010 at 11:26

[GoogleCodeExporter]

I reverted EOF back to using its original delta->realtime conversion formula 
until we get actionable information.  r448 adds support for custom time 
signatures.  MIDI import will still build a list of all time signatures read, 
and still passes them to eof_ConvertToRealTimeInt(), but they won't use them 
for timing conversion.  When the correct formula is found, it will be easy to 
make the change in EOF.  The EOF project's time signatures still are not used 
for MIDI import/export.

Original comment by raynebc on 9 Oct 2010 at 10:43

[GoogleCodeExporter]

r454 implements probably what amounts to the majority of the remaining logic 
for handling time signatures.  Currently MIDI import isn't working quite right, 
as the tempo map creation creates too many beats and fails.  The logic that 
determines how many beats to create at each tempo change will need to be 
updated.

Original comment by raynebc on 11 Oct 2010 at 10:35

[GoogleCodeExporter]

The MIDI import logic tries to determine the beat length and count by measuring 
the distance between anchors, but this doesn't take time signatures into 
account.  The tempo map logic should be rewritten to create everything in one 
loop instead of several.

Original comment by raynebc on 12 Oct 2010 at 6:15

[GoogleCodeExporter]

r459 fixes MIDI import from what I can tell so far.

Original comment by raynebc on 12 Oct 2010 at 11:13

[GoogleCodeExporter]

It looks like non #/4 time signatures aren't working correctly for some reason. 
 If I make a chart any time signature with a denominator of anything besides 4, 
save and import the MIDI, the notes don't import with correct timings.

Original comment by raynebc on 12 Oct 2010 at 11:52

[GoogleCodeExporter]

Original comment by raynebc on 13 Oct 2010 at 6:58

• Changed title: Add native time signature support

[GoogleCodeExporter]

The MIDIs for some charts I've made will export and import with time signatures 
correctly, but "Fire and Ice" has problems with the notes being skewed:
http://www.sendspace.com/file/j425ie

Original comment by raynebc on 14 Oct 2010 at 2:47

• Added labels: Type-Defect
• Removed labels: Type-Enhancement

[GoogleCodeExporter]

When I import that MIDI into Anvil Studio, the notes appear to be bunched up, 
seeming to point to this being a MIDI export issue.

Original comment by raynebc on 14 Oct 2010 at 7:10

[GoogleCodeExporter]

However, the MIDI notes themselves appear to be correct.  With a time signature 
of 5/1 and a time division of 480, the expected length of one beat is 120 
deltas (480 * 1 / 4).  With this in mind, all drum note timings are placed on 
or within 1 delta of their appropriate grid snap positions.

Also, during import, the drum note count is 698 instead of the expected 742.  
I'm not sure if zero-length notes are being cleaned out or if the import logic 
is malfunctioning otherwise.  Despite the note problems, the tempo map appears 
to import and export flawlessly.

Original comment by raynebc on 14 Oct 2010 at 7:21

[GoogleCodeExporter]

For the coming stable release, it would probably be best to make it a user 
option about whether to import/export Time Signature events from/to MIDI files.

Original comment by raynebc on 20 Oct 2010 at 5:02

[GoogleCodeExporter]

Original comment by raynebc on 20 Oct 2010 at 5:03

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

r488 adds the "Import/Export MIDI TS" option, so even if the time signature 
handling isn't 100% stable, it will be the user's decision to use it at his/her 
own risk while still being able to have the convenience of safely charting with 
time signature changes.

Original comment by raynebc on 21 Oct 2010 at 8:10

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

r489 fixes a couple bugs with this logic, and MIDI import/export both work 
again if time signatures are disabled.  MIDI time signature handling is still 
unstable.

Original comment by raynebc on 21 Oct 2010 at 11:36

[GoogleCodeExporter]

r497 works on this some more, fixing a couple issues.  It's getting close, but 
it's still not fully working.  I made a sample chart to help test the TS logic 
for saved/imported MIDIs:
http://www.sendspace.com/file/74kvbc

Once the saved MIDI imports and looks correct, this issue will likely be 
completed.

Original comment by raynebc on 24 Oct 2010 at 1:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

r498 makes a breakthrough with the import by fixing the beat millisecond 
lengths to only respect the current tempo and disregard the time signature 
(which at this point I believe only affects delta timing).  I posted my updated 
formulas on the forum for peer review, but I believe this is now stable.

Original comment by raynebc on 24 Oct 2010 at 6:16

[GoogleCodeExporter]

I'm going to consider this logic working unless a problem is found.  It may be 
a good idea for the TS changes to be stored in the same list as the tempo 
changes to avoid having to maintain them as two separate lists.  This will make 
the logic cleaner and will port more nicely to FoFLC.

Original comment by raynebc on 1 Nov 2010 at 7:53

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

r517 adds untested logic for EOF to load time signatures during Feedback chart 
import.

Original comment by raynebc on 1 Nov 2010 at 8:58

[GoogleCodeExporter]

I tested a couple of charts, the TS import for Feedback charts seems to work 
just fine.

Original comment by raynebc on 1 Nov 2010 at 9:09

[GoogleCodeExporter]

A sufficient amount of time has passed and nobody identified any problems with 
this logic, so I'll consider this feature complete for now.

Original comment by raynebc on 10 Nov 2010 at 12:58

• Changed state: Fixed