Add support for pro guitar

[GoogleCodeExporter]

This will be a long term enhancement, as several other things need to be 
completed first for EOF to support first (6 lane track, different notes 
starting at the same position with different lengths, etc).

When the time comes, I came across some useful information about the pro guitar 
format:
http://rawksd.japaneatahand.com/wiki/PRO_Mode_Research

Original issue reported on code.google.com by raynebc on 6 Dec 2010 at 3:43

[GoogleCodeExporter]

27.  Determine how to accurately detect "slash" guitar chords.  This will 
probably need to be a second chord lookup function performed if the chord is 
not detected as a standard chord.

Original comment by raynebc on 1 Jun 2011 at 10:25

[GoogleCodeExporter]

r773 begins work on task 24.  Chords that are recognized have the correct root 
note (scale identifier) written, and unrecognized chords are written with a 
root note of 9 (A scale).  It could use some logic to check existing note names 
first, so chords that aren't recognized (ie. ones that use an interval higher 
than 7) and were named by the user have the scale taken from the name, ie. it 
would return nonzero if the passed string began with a scale that was 
recognized, ie. "Abmaj" would detect as scale Ab, "A#5" would detect as scale 
Bb, etc.  Having a second array of string names that had the opposite 
accidentals as eof_major_scale_names[] would allow the correct scale to be 
recognized regardless of whether the charter prefers sharps or flats:

char *eof_major_scale_names2[12] 
=   {"A","A#","B","C","C#","D","D#","E","F","Gb","G","G#"};

Finding a match would be as easy as using extracting the scale from the 
beginning one or two characters of the note name into a string.  The note name 
would be capitalized and the accidental lowercase (if flat).  Then strcmp() 
could be used to check for an appropriate match in eof_major_scale_names[] and 
eof_major_scale_names2[] to find the appropriate scale number.  The determined 
scale number would be stored through a pointer and the match status returned (0 
or nonzero).

Original comment by raynebc on 2 Jun 2011 at 1:01

[GoogleCodeExporter]

28.  Create an option to write a RBN compliant MIDI (notes_RBN.mid) during 
save, which will omit unsupported chart features (ie. slide sections, open 
bass, PART DANCE, expert+ drum notation).  Expert drums should be written as 
normal bass drum notes as they are in the expert+.mid logic.  This would make 
it convenient to prepare an RBA file in Magma because the full MIDI wouldn't 
have to be edited to remove unsupported tracks, notations, etc.

The RBN compliance should run before the save occurs, verifying several 
criteria are met and offer suggestions, such as:

1.  As per RBN2 documentation, the first gem should not be closer than 3 
seconds from the beginning of the chart (this is how long the gamertag and/or 
other song information is displayed during the beginning of a song).  If this 
is not the case, advise the user to use Song>Leading Silence to pad to (3000ms 
- first notepos), using the options to re-encode the audio and adjust 
notes/beats.  Having it open the Leading Silence menu with those settings (if 
user opted to perform the suggested change) would be an added convenience for 
the user.
2.  The MIDI delay should be 0.  If not, prompt the user to use "Beat>Reset 
offset to zero".  If the user opts to perform the change, call the function for 
convenience.
3.  For each of the 5 lanes, if it is used in one track difficulty, at least 
one gem of that lane must exist in the other track difficulties.

Original comment by raynebc on 3 Jun 2011 at 7:12

[GoogleCodeExporter]

I've discovered several interesting MIDI details and posted them here:
http://www.fretsonfire.net/forums/viewtopic.php?f=1&t=50349&p=590927#p590927

For task 24:
Write a root note of 17 for chord names that cannot have their scale 
determined.  Scale detection for manually named (check name for a 
forward/backward slash) or automatically detected (task 27) slash chords will 
need to write a note 16 root note in addition to the main chord's scale (ie. 
Fm7/E is written with root notes 5 and 16).

For task 23:
Use RB3's system of "[chrd1 ...]", "[chrd2 ...]" and "[chrd3 ...]" text events 
(ie. Text Event="[chrd1 Bb5]" for Medium difficulty chord name) to manually 
override the game's chord name detection for Medium, Hard and Expert 
difficulties, respectively.  This means that custom Sysex phrase markers will 
not be used for chord names.

Original comment by raynebc on 4 Jun 2011 at 11:31

[GoogleCodeExporter]

r778 completes task 23 and updates the MIDI export to write a root note of 17 
for any chord whose scale cannot be detected.

Original comment by raynebc on 8 Jun 2011 at 3:29

[GoogleCodeExporter]

r779 added some logic on slash chords, but it doesn't look like it will be 
feasible to determine each chord's original bass note (needed in order to 
determine if a variation of that chord is a slash chord) without either of the 
following:
1.  Having a static list of all chords and their bass notes
2.  Dynamically building a list of a matched chord's variations, determine the 
bass  note of each, and compare each variation with the chord being looked up.

Option 2 is more feasible, but would either require:
2a.  Variations to be generated for each lookup, which would make successful 
lookups take longer.

or

2b.  During the launch of EOF (and every time the tuning changes), build a 3D 
array of all valid variations of each defined chord in each scale, storing the 
bass note for each variation.  This is bizarre, but it should minimize lookup 
time on a per chord basis.  The first two dimensions would be scale and chord 
(each would be a static value, which could be defined by a macro.  The third 
dimension would be the variations of each chord, and would have to either be 
tracked by a counter (more complicated) or be marked at the end with an array 
termination value such as 0 (easier).  The structure for the third dimension 
would be something like:

typedef struct
{
    unsigned char defined;          //If this is 0, it marks the end of the dimensional array
    unsigned char frets[EOF_TUNING_LENGTH]; //The fretted position of each string
    unsigned char bassnote;         //The bass note of the chord
} EOF_CHORD_BASS_NOTE;

Original comment by raynebc on 8 Jun 2011 at 5:46

[GoogleCodeExporter]

r780 adds chord and slash chord detection for manually named notes.  I tested 
it against a note manually named as a slash chord, and the exported MIDI that 
was written included the slash chord indicator (note 16).  This means that task 
#24 can be considered completed.  The ability for automatically named slash 
chords to be written to MIDI as slash chords depends on task 27.

Original comment by raynebc on 9 Jun 2011 at 12:00

[GoogleCodeExporter]

29.  Add 22 fret pro guitar and pro bass to the default tracks in a new project.

Original comment by raynebc on 12 Jun 2011 at 6:57

[GoogleCodeExporter]

r781 works on issue 27 by adding logic to build a 3D array of variations for 
each chord from each scale (an 11 fret version, which should work during lookup 
just by doing (fret # % 12) on each fret before checking against this array) 
which may ultimately be useful for detecting slash chords.  The building of 
this array is still slow (it checks all string/fret permutations for chord 
matches), where a faster version may be to build variations from the chord 
formulas themselves.

Original comment by raynebc on 12 Jun 2011 at 11:11

[GoogleCodeExporter]

r804 adds 22 fret pro guitar and bass track support.

Original comment by raynebc on 24 Jul 2011 at 10:15

[GoogleCodeExporter]

r824 completes task 28 except for on-demand RBN compliance testing.  The "Save 
separate RBN MIDI files" preference will have EOF save additional RBN and pro 
upgrade MIDI files that strip out all unsupported chart features (ie. non pro 
guitar tracks and global events from a pro upgrade MIDI, FoF specific tracks 
like PART GUITAR COOP from a RBN MIDI).

Original comment by raynebc on 16 Sep 2011 at 4:09

[GoogleCodeExporter]

Tasks 17 and 18 have already been fixed in the editor logic, as when I 
add/remove a gem from a pro guitar note, that note is automatically selected, 
and when I paste notes, the selection is changed to the newly pasted notes.

Task 21 can be considered done.  According to findings from other customs 
authors, both hammer on and pull off notes are marked with the MIDI note one 
note higher than lane 6.  It's not necessary worth a large amount of effort to 
add complex logic to determine whether an imported note would be treated as HO 
or PO by a game, EOF currently imports all such notes as HO.

Task 22 can be considered done.  Import and export logic for custom phrase 
Sysex markers (issue 196) has been added, and new phrases should be able to be 
added easily.

Task 28 can be considered done.  I've decided against making an RBN compliance 
test function at this time, because there are exceptions to most rules (ie. if 
creating a pro guitar upgrade, using a MIDI delay to sync with user-recorded 
audio would be common).

Remaining tasks for this issue are:
6. Implement the MIDI import logic.  Test with RB3 MIDIs.
7. Implement the MIDI export logic.  Test with beta version of Phase Shift 
provided by thekiwimaddog.
13. Add a chord catalog mechanism.  Each time a unique chord is the result of a 
pro guitar note edit (use the currently-uncreated abstracted note comparison 
function), and it defines legacy transcription, add it to a chord catalog 
(which stores the note number).  If an edit makes a chord catalog entry not a 
chord anymore, remove it from the chord catalog.  Each time an edit operation 
makes a chord use the same pro fretting as an existing chord catalog entry, 
automatically use the entry to duplicate the legacy transcription (user prompt 
after using OK to close the edit note dialog).  Make this system a user option 
(enabled by default).  It would probably be better to generate a list of unique 
chords for the active pro guitar track when the feature is invoked.  The method 
used in the pro guitar note edit function to prompt for each unique name/legacy 
mask should work for building a list of unique chords.  Then a bitmap can be 
generated that is large enough to render all of the chord catalog entries to, 
where each entry consists of the name, the pro guitar rendering of the chord 
(each note and fret value) and the legacy view of the chord.  The easiest way 
to adapt the rendering without duplicating code would be to separate the render 
logic to the point where a function with an (x,y) screen coordinate indicating 
where lane 6 of the note would render.  The legacy view variable could be 
toggled in between calls to allow the pro guitar note followed by the legacy 
view of the note could be rendered for each catalog entry.  The bitmap the 
chord catalog is rendered to would need to be scrollable, or if Allegro won't 
do that natively, it may need to be handled with a scroll bar, Pg Up/Dn or 
arrow keys.
15.  A user suggested that we could try to add support for pro guitar files.  
Apparently there are multiple revisions of the pro guitar file spec, and only 
some of them are publicly known.  This probably won't be worth the effort 
unless we support a revision of the pro guitar file standard that is 
permanently supported by the free TuxGuitar alternative.  As long as TuxGuitar 
can save to the single pro guitar standard (or perhaps even an open standard) 
tab format that EOF supports, people will be able to save other formats to the 
supported format and use with EOF.
16. Look into the ability to set hotkeys, such as ALT+P and ALT+N to activate 
the previous/next note buttons that would be added from issue 229.
25.  Add the ability to mark vibratos, bends, tapping, palm muting and maybe 
pre-bends, using custom phrase markers for MIDI import/export (as per the 
specifications in issue 196).
27.  Determine how to accurately detect "slash" guitar chords.  It has been 
suggested that a chord is a slash chord in general if the bass note (lowest 
pitch note) played is not the root note (the scale of the chord that is formed 
by the notes played.  I need to verify this convention by checking the 
"Inverted Chords" trainer in RB3, as well as one or more charts that display 
slash chords.

Original comment by raynebc on 28 Sep 2011 at 8:04

[GoogleCodeExporter]

I'm going to consider task 27 completed.  EOF will recognize true slash chords, 
and has a user preference for whether inverted chords (the chord's root is not 
the bass note) are treated as slash chords.

Original comment by raynebc on 24 Oct 2011 at 9:53

[GoogleCodeExporter]

Regarding task 25, I'd also like to allow notes to be marked as harmonics.

Original comment by raynebc on 31 Oct 2011 at 11:07

[GoogleCodeExporter]

Since input fields in the edit pro guitar note dialog can block/accept input, 
the only way to make task 16 work is to add special handling by checking to see 
if ALT is being held in addition to the desired shortcut key.  I posted on the 
Allegro forum to ask if this is possible 
(http://www.allegro.cc/forums/thread/608829), but I suspect it will require 
some custom dialog logic to be designed.

Original comment by raynebc on 16 Nov 2011 at 9:28

[GoogleCodeExporter]

Regarding task 15, Guitar Pro parsing logic and a file spec have been 
previously added to EOF's file base.

Regarding task 25, Harmonix's notation for bends, tapping and harmonics has 
been adopted.  Pre-bends are not nearly as common as Vibrato and palm muting, 
so those statuses should be given Sysex markers for import/export.

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

[GoogleCodeExporter]

Regarding task 25, I'm going to consider pre-bends unimportant at this time.  
Vibrato and palm muting have been given their own Sysex markers.  It may turn 
out that Harmonix uses separate MIDI channels to denote pinch harmonics from 
other harmonics, but that isn't confirmed.  If it is, I'll want to add support 
for them as well.

Original comment by raynebc on 26 Sep 2012 at 7:51

[GoogleCodeExporter]

Regarding task 15, r975 added initial support for importing pro guitar files.  
It needs testing against more files, but it seems to process two files I have 
perfectly fine.  The feature itself could use some more polishing in terms of 
allowing a full import (creating a project from scratch via a GP file), adding 
a dialog menu where the user can match guitar pro tracks with pro guitar tracks 
in EOF.

I'm going to consider tasks 6 and 7 completed, since as far as I can tell, all 
known RB3 notations are imported and exported.  I'm going to consider task 16 
unimportant.

Remaining tasks for this issue are:
13. Add a chord catalog mechanism.  Each time a unique chord is the result of a 
pro guitar note edit (use the currently-uncreated abstracted note comparison 
function), and it defines legacy transcription, add it to a chord catalog 
(which stores the note number).  If an edit makes a chord catalog entry not a 
chord anymore, remove it from the chord catalog.  Each time an edit operation 
makes a chord use the same pro fretting as an existing chord catalog entry, 
automatically use the entry to duplicate the legacy transcription (user prompt 
after using OK to close the edit note dialog).  Make this system a user option 
(enabled by default).  It would probably be better to generate a list of unique 
chords for the active pro guitar track when the feature is invoked.  The method 
used in the pro guitar note edit function to prompt for each unique name/legacy 
mask should work for building a list of unique chords.  Then a bitmap can be 
generated that is large enough to render all of the chord catalog entries to, 
where each entry consists of the name, the pro guitar rendering of the chord 
(each note and fret value) and the legacy view of the chord.  The easiest way 
to adapt the rendering without duplicating code would be to separate the render 
logic to the point where a function with an (x,y) screen coordinate indicating 
where lane 6 of the note would render.  The legacy view variable could be 
toggled in between calls to allow the pro guitar note followed by the legacy 
view of the note could be rendered for each catalog entry.  The bitmap the 
chord catalog is rendered to would need to be scrollable, or if Allegro won't 
do that natively, it may need to be handled with a scroll bar, Pg Up/Dn or 
arrow keys.
15.  Improve support for pro guitar files.  If no chart is already loaded, a 
blank chart should be created, the user prompted to map tracks from the guitar 
pro file to pro guitar tracks in EOF, and the user should select an audio file. 
 The import logic needs to be tested against more files.
30.  Add a pro guitar tutorial.  It should discuss each of the pro guitar game 
mechanics, charting methods (including the keyboard shortcuts) and the general 
process for creating a pro guitar upgrade for Rock Band DLC.

Original comment by raynebc on 2 Oct 2012 at 5:10

[GoogleCodeExporter]

Task #15 is regarding Guitar Pro files.

Original comment by raynebc on 5 Oct 2012 at 7:00

[GoogleCodeExporter]

Task 13 doesn't sound like it would be worth the effort to implement it as 
described.  Task 15 is generally complete, there are only a couple things I 
know of that haven't been tested such as trill notation, but I'll resolve 
issues as they are found.  The enhancement of making a chart creation file 
import variation isn't a high priority issue, since it only saves the step of 
creating a chart before import.  Task 30 has been completed.  That more or less 
completes this issue.

Original comment by raynebc on 29 Oct 2012 at 9:07

• Changed state: Fixed