Change how EOF uses tracks

[GoogleCodeExporter]

Currently, EOF stores tracks in a static manner, where the guitar track is 
track 0, etc.  This becomes less scalable when more tracks are added, such as 
secondary guitar tracks, pro tracks, etc.  Generally, the track number is only 
checked to allow certain actions to be taken (such as ensuring "crazy" status 
can only added to notes in a guitar track), but as there become more and more 
guitar type tracks (guitar, lead guitar, rhythm guitar, bass, pro bass, pro 
guitar, etc), it increases the amount of checking necessary.  If each track had 
a behavior (allowed for in the proposed EOF project file format) variable that 
describes whether it acts like a guitar track, it will make this type of 
checking easy.

Track can be stored similarly to notes, in an array of track objects.  
Potentially, the new chart wizard could still allow the user to create a 
"standard" project with the typical tracks created by default.

But if the user chooses to create a "custom" project, I propose that EOF not 
add any tracks automatically, but allow the user to add tracks to the project 
through a menu function such as Song>Track>Add.  The Add menu item can have 
presets like PART GUITAR, but will also allow the user to manually select which 
type of track to add (guitar, drum, vocal, keys, pro guitar, pro keys, etc) and 
provide the name of the track.  Once they select the track type, there can be a 
second dialog screen with some other type specific options, such as whether the 
bass track will allow GH style open bass (requiring a sixth lane), how many 
frets are used in the pro guitar track (17 or 22), etc.

Users should also be able to manually add new tracks to their "standard" 
project.  The track cycling functions (ie. CTRL+Tab) could simply iterate 
through the defined tracks in the array.

A delete track function could be in the Song>Track submenu, but should only be 
allowed if the track is completely empty of all notes.  If the only track that 
is open contains any tempo changes, it should not be allowed to be deleted (so 
users can't accidentally destroy their tempo map).

Original issue reported on code.google.com by raynebc on 17 Nov 2010 at 9:14

[GoogleCodeExporter]

Just clarifying that the current behavior does not add any tracks by default 
and only the tracks you add notes to are exported to the MIDI. Personally, I 
would rather have the process work as you described above. Aside from that I 
think the tempo map should be decoupled from the other tracks so you don't have 
to have any other tracks to be able to keep the tempo map. I think it would be 
cool to have an empty chart come up to a tempo map editor so you can map the 
tempo before adding any tracks.

Original comment by xander4j...@yahoo.com on 17 Nov 2010 at 10:30

[GoogleCodeExporter]

I really like that idea and it would make it easier to handle something I 
requested before:  An option to export only the tempo map in order to recover 
from bizarre conditions.

Original comment by raynebc on 17 Nov 2010 at 10:54

[GoogleCodeExporter]

Original comment by raynebc on 18 Nov 2010 at 11:54

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

[GoogleCodeExporter]

It may also be a good idea to either use dynamically allocated strings to store 
items such as file names and tags, or make the arrays all the same length 
(using a macro definition) to guarantee consistency.

Original comment by raynebc on 18 Nov 2010 at 11:59

[GoogleCodeExporter]

Original comment by raynebc on 19 Nov 2010 at 7:01

• Changed state: Started

[GoogleCodeExporter]

r574 adds some track addition/deletion logic for storing a flexible number of 
tracks, but it is still tied to EOF_TRACKS_MAX for the time being (ie. for 
cycling tracks).  Eventually, eof_song->tracks can be used instead.  I had to 
add an additional check in eof_detect_difficulties() to prevent it from causing 
an out of bounds de-reference in the tracks array, although I haven't 
investigated a lot of thought into why this problem came up yet.

The next step would be to move the track additions into the import logic 
itself, as even though the legacy imports need a preset number of tracks, the 
new import will not.

Original comment by raynebc on 19 Nov 2010 at 8:50

[GoogleCodeExporter]

r576 makes a large set of changes to accomplish the abstraction of the track 
array.  The way I imagine it could work nicely is that eof_song->track[] is an 
array of structures.  Each of the track entry structures defines which track 
type it is, and which index into the track of that type refers to the track 
data.  There will be many things that have to change to accommodate this, but I 
can't think of a better way to have track #X be able to refer to any type of 
track, regardless of whether it is a legacy style, vocal, pro keys or pro 
guitar track.

Original comment by raynebc on 20 Nov 2010 at 12:42

• Changed state: Accepted

[GoogleCodeExporter]

The original track numbering macros (ie. EOF_TRACK_GUITAR) will need to be 
changed to begin with number 1, so that number 0 is reserved for the "global" 
track to maintain consistency with the new EOF project format.  This shouldn't 
affect to much except for code that is designed to assume EOF_TRACK_GUITAR is 
0, such as the instrument cycling keyboard combo, etc.

Original comment by raynebc on 22 Nov 2010 at 8:23

[GoogleCodeExporter]

As of r582, the new track handling system is partially implemented.  Most of 
the track manipulation functions simply operate on 
legacy_track[eof_selected_track], but they will need to instead operate on 
sp->track[eof_selected_track].  This would likely require abstraction code to 
check whether the track format is a legacy format, in order for the functions 
to be ready to handle other track formats in the future.

Original comment by raynebc on 22 Nov 2010 at 9:33

[GoogleCodeExporter]

Correction:
The correct way to access legacy_track[], as long as eof_selected_track 
references a legacy track, is 
eof_song->legacy_track[eof_song->track[eof_selected_track]->tracknum]

This is much more complex than before, but it's probably one of the more 
elegant means to allow EOF to refer to any type of track with 
eof_selected_track.

Original comment by raynebc on 22 Nov 2010 at 9:51

[GoogleCodeExporter]

And any function that originally accepted a track pointer and manipulated the 
track would likewise need to be modified to accept a track number instead.

Original comment by raynebc on 22 Nov 2010 at 9:54

[GoogleCodeExporter]

r583 makes most or all of the updates for accessing the legacy_track[] array.  
Abstracting the functions into accessing the main track[] array to check the 
track format remains to be completed but will only be necessary when 
implementing the new track formats (ie. pro guitar).

Original comment by raynebc on 22 Nov 2010 at 10:13

[GoogleCodeExporter]

r591 fixes MIDI import's handling of the legacy track data.  Chart import will 
probably need the same.

Original comment by raynebc on 26 Nov 2010 at 4:10

[GoogleCodeExporter]

MIDI import should eventually check the imported track name against the 
eof_default_tracks[] array, since that is where all the pre-defined track 
names, behaviors, etc. will be kept.

Original comment by raynebc on 30 Nov 2010 at 7:23

[GoogleCodeExporter]

r607 implements that logic by creating a separate array defining the valid MIDI 
track names that can be imported, along with other details such as which track 
entry they are stored into, etc.

Original comment by raynebc on 2 Dec 2010 at 9:54

[GoogleCodeExporter]

r613 renamed legacy track handling functions to separate them from what the pro 
track handling functions would be called.  Eventually, it would probably be 
nice to have generic track manipulation functions such as 
eof_track_sort_notes() that accept the track number instead of a pointer, and 
the appropriate logic will be used based on the track's format.

Original comment by raynebc on 8 Dec 2010 at 9:07

[GoogleCodeExporter]

r631 abstracts many track manipulation functions.  Track format specific 
manipulations should be removed as much as possible, preferably limited to 
track format specific cleanup routines like eof_legacy_track_fixup_notes().

Original comment by raynebc on 18 Dec 2010 at 10:41

[GoogleCodeExporter]

r637 makes great progress on this, but a majority of the remaining references 
to "->legacy_track" will likely need to be abstracted, otherwise the logic will 
not work for pro guitar.  Once all logic has been updated, there will probably 
be plenty of room for more code de-duplication.

Original comment by raynebc on 21 Dec 2010 at 7:28

[GoogleCodeExporter]

There are over 700 references to "->legacy_track", so the next major 
breakthrough on this enhancement may take a while.

Original comment by raynebc on 21 Dec 2010 at 7:47

[GoogleCodeExporter]

r638 makes a huge amount of progress.  About one third of the legacy_track[] 
references have been updated with new logic.  So far, I have left some of the 
original logic alone (such as in eof_import_midi and eof_menu_song_open_bass), 
since many of the references to the legacy_track[] array was for track-specific 
special handling.

After this, the vocal_track[] references would ultimately need to be similarly 
updated for future compatibility with multiple vocal tracks and/or vocal 
harmonies.

Original comment by raynebc on 22 Dec 2010 at 8:25

[GoogleCodeExporter]

r640 updates about half of the remaining references to legacy_track[].

Original comment by raynebc on 23 Dec 2010 at 12:37

[GoogleCodeExporter]

r641 updates the remaining legacy_track[] references that needed to be changed. 
 The legacy chart and Feedback import code was not changed.  Neither was the 
Feedback editor logic, since the import code is track specific and the editor 
code is unused.  Neither was the INI export for the open bass tag.

Original comment by raynebc on 23 Dec 2010 at 4:15

[GoogleCodeExporter]

There are over 450 references to vocal_track[], but the updates to those 
references can wait until issue 197 (vocal harmonies) is worked on.

Original comment by raynebc on 23 Dec 2010 at 5:50

[GoogleCodeExporter]

Original comment by raynebc on 23 Dec 2010 at 5:50

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

[GoogleCodeExporter]

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

• Changed state: Started

[GoogleCodeExporter]

This probably won't be continued until vocal harmony support is worked on after 
the 1.8 stable release.

Original comment by raynebc on 18 May 2012 at 6:34

• Changed state: On_Hold