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]

6 lane input and 2D rendering logic is completed.  Issue 211 (the ability to 
have different length notes at the same starting position) isn't very import 
for this enhancement, since that's not common in guitar playing.  
Comparatively, arpeggios/broken chords should be handled just fine as "crazy" 
notes.

thekiwimaddog has started a thread about the MIDI conventions used in pro 
guitar charts:
http://www.fretsonfire.net/forums/viewtopic.php?f=1&t=50349

Some tasks for this enhancement:
1. Making the pro guitar track a default track, making it a 6 lane track.
2. Implement logic for adding pro guitar notes, with a default fretting of 
(muted).
3. Update the 2D rendering to be able to show the fret number of each note's 
frets.
4. Update the 3D rendering to support 6 lane display and to show the fret 
number for each note's frets.
5. Implement a menu dialog (invoked by menu or via keyboard combination) to 
bring up a dialog window for defining a pro guitar note's frets (one text input 
box for each fret).  This dialog should contain checkboxes and/or radio buttons 
for specifying flags for the note, such as whether it slides up/down to the 
next note.  This dialog could be recycled for pro bass charting later.
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.

Original comment by raynebc on 18 Dec 2010 at 2:16

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

[GoogleCodeExporter]

8. Update the chart save/load logic.

r630 completes task 1.  For now, I'll add the pro bass track as well.

Original comment by raynebc on 18 Dec 2010 at 8:53

• Changed state: Started

[GoogleCodeExporter]

r631 and r632 complete task 8.

Original comment by raynebc on 18 Dec 2010 at 11:24

[GoogleCodeExporter]

r633 begins work on task 2.

Original comment by raynebc on 20 Dec 2010 at 12:54

[GoogleCodeExporter]

r634 completes task 2.

9. Abstract the rest of the note manipulation functions similarly to how the 2D 
rendering was (such as using eof_get_note_pos) to work with both legacy and pro 
guitar notes.

Original comment by raynebc on 20 Dec 2010 at 6:11

[GoogleCodeExporter]

r635 completes task 3.

Original comment by raynebc on 20 Dec 2010 at 7:00

[GoogleCodeExporter]

10. Compare RB3 MIDIs to the actual charts to determine how various features 
such as note slides are implemented.

Original comment by raynebc on 20 Dec 2010 at 7:23

[GoogleCodeExporter]

r636 begins work on task 4.

Original comment by raynebc on 21 Dec 2010 at 2:50

[GoogleCodeExporter]

r637 completes task 4 and begins task 9.

So far, one bug I haven't resolved is that after adding a pro guitar note, it 
isn't automatically selected.

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

[GoogleCodeExporter]

11. Implement a way to increment/decrement a selected pro guitar note's frets.  
For example, incrementing from muted would go 0, 1, etc.  When the highest 
usable fret was incremented (ie. 17), it could go back to 0xFF (muted).  
Shift+Up/Down appears to be available for such a use, as it's currently only 
used for manipulating lyrics.

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

[GoogleCodeExporter]

r645 fixes the bug where newly added pro guitar notes weren't automatically 
selected.  The last several commits finished task 9.  That leaves the following 
tasks:

5. Implement a menu dialog (invoked by menu or via keyboard combination) to 
bring up a dialog window for defining a pro guitar note's frets (one text input 
box for each fret).  This dialog should contain checkboxes and/or radio buttons 
for specifying flags for the note, such as whether it slides up/down to the 
next note.  This dialog could be recycled for pro bass charting later.
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.
10. Compare RB3 MIDIs to the actual charts to determine how various features 
such as note slides are implemented.

Original comment by raynebc on 23 Dec 2010 at 7:39

[GoogleCodeExporter]

r646 completes most of task 5, the function (eof_menu_note_frets) just needs to 
be added to the Note menu.

Original comment by raynebc on 24 Dec 2010 at 12:33

[GoogleCodeExporter]

11.  Display chords in the information window, such as "x32010" for an open C 
chord.  Use capital 'X' for an unplayed string versus lower case 'x' for a 
muted string.  I still don't know whether it's more traditional to list the 
thickest or the thinnest string first in this style of notation.

Original comment by raynebc on 24 Dec 2010 at 2:16

[GoogleCodeExporter]

12.  Implement a shortcut method to set the fret number of the selected note's 
strings using ALT+# (non numpad).  This would be easy to implement for setting 
notes to fret values of 0 (open) through 9, but something for the upper frets 
would be more complicated.  I see that ALT+Function key may work, but it could 
be problematic to get that working with how EOF intercepts the ALT key for 
using opening the main menus.  CTRL+Function key appears workable though, and 
I'd just have to make sure the existing function key shortcuts ensured neither 
CTRL was being held before launching their function.

Original comment by raynebc on 24 Dec 2010 at 9:24

[GoogleCodeExporter]

r647 adds the menu item to edit a note's frets, but the note flag controls for 
that dialog menu can't be added until the available charting mechanics are 
enumerated (ie. sliding.  Sliding would be one of the few mechanics that would 
require a radio button set instead of a checkbox, having "no slide", "slide up" 
and "slide down", because only one of those should be applied at once to any 
note.  Eventually, the name of the menu item and dialog window title may need 
to change to reflect that the note is being edited and not just the frets.  
This would like require the shortcut key to change.  'N' looks like it's 
available.

Original comment by raynebc on 24 Dec 2010 at 9:41

[GoogleCodeExporter]

r648 completes task 5.  It also allows the user to pre-define how a pro guitar 
will transcribe to a legacy style note when pasted into a legacy track.

Original comment by raynebc on 27 Dec 2010 at 1:21

[GoogleCodeExporter]

r649 adds many pro guitar note manipulation functions and keyboard shortcuts, 
as well as tab style rendering of playing mechanics.

Original comment by raynebc on 27 Dec 2010 at 7:24

[GoogleCodeExporter]

Regarding task 12, I will probably want to move the toggle lane 1-6 functions 
from CTRL+# to SHIFT+# (since that won't conflict with vocal mode's function to 
change the visible octave).  This will allow CTRL+# and CTRL+Fn key to be 
available for assigning the fret numbers for the selected notes.  CTRL+tilde 
can be used to assign a value of 0, where CTRL+0 would assign a fret value of 
10.  CTRL+F1 through CTRL+F12 can assign fret values of 11 through 22.  CTRL+X 
can assign string mute.  This is the best way to maintain consistency of using 
CTRL keyboard shortcuts to manipulation pro mode features.

Original comment by raynebc on 27 Dec 2010 at 3:26

[GoogleCodeExporter]

r650 adds abstracted note comparison and select like functionality.  This will 
make it easier to add another feature:

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).

Original comment by raynebc on 27 Dec 2010 at 9:18

[GoogleCodeExporter]

r652 adds trill and tremolo phrases.  They both use a specialized 2D and 3D 
phrase rendering that renders one lane's width of a color centered over the 
gem's fret line.

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

[GoogleCodeExporter]

Regarding task 11, it appears to be much more popular to display chords with 
the highest numbered string first (ie. an open C chord as x32010), so the text 
string would just have to be built starting with frets[5] and working down to 
frets[0].  To address multi digit fret values, there will be a space in between 
each.  For example, open C would display as "X 3 2 0 1 0".

Original comment by raynebc on 28 Dec 2010 at 6:06

[GoogleCodeExporter]

r654 completes task 12 and adds rendering of pro guitar slides.  That leaves 
the following tasks:

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.
10. Compare RB3 MIDIs to the actual charts to determine how various features 
such as note slides are implemented.
11.  Display chords in the information window, such as "x32010" for an open C 
chord.  Use capital 'X' for an unplayed string versus lower case 'x' for a 
muted string.  I still don't know whether it's more traditional to list the 
thickest or the thinnest string first in this style of notation.
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).

Original comment by raynebc on 29 Dec 2010 at 6:46

[GoogleCodeExporter]

r656 completes task 11.  I decided to use underscore to represent an unused 
string, to avoid confused with the notation for a muted string.  It also adds 
the logic to edit pro guitar note names, which are kept during most/all 
operations including pasting them into a legacy track.

Original comment by raynebc on 31 Dec 2010 at 9:04

[GoogleCodeExporter]

r658 and r659 adds logic to automatically get or set pro guitar names for 
matching notes after a note is defined with or without a name.

Original comment by raynebc on 3 Jan 2011 at 8:22

[GoogleCodeExporter]

Regarding task 13, 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.

Original comment by raynebc on 9 Jan 2011 at 7:52

[GoogleCodeExporter]

r676 has begun work on task #6.  Pro guitar notes and fret values appear to 
import properly.  To determine how all of the various phrases and playing 
techniques are denoted, I'm considering adding a system similar to the 
following:

14.  Have each track store an additional array of EOF_NOTE structures.  The 
channel can be stored in the second lowest flag byte, and the velocity can be 
stored in the lowest flag byte.  Apply special fretboard rendering (such as 
solid white rendering, taking the whole height of the editor window, so that 
it's visible even when a solo/arpeggio section is rendered) for such undefined 
notes in order to indicate where they are in the chart.  Come up with a means 
for showing these notes, a scrollable text window showing all such notes from 1 
second before to 1 second after the seek position would work well.

Original comment by raynebc on 12 Jan 2011 at 9:06

[GoogleCodeExporter]

r691 has begun work on task #7.

Original comment by raynebc on 21 Jan 2011 at 8:42

[GoogleCodeExporter]

Considering that I've already obtained pretty much all the RB3 MIDI standard 
through my own analysis of several MIDIs, task #10 can generally be considered 
completed.  I think task #14 can be skipped.  If custom MIDI markers are added 
to EOF in the future, a similar storage method can be implemented.  Due to how 
quickly EOF keeps up with emerging standards, it probably won't be that 
important of a feature.

Until user testing of the import/export is completed, tasks #6 and 7 will 
remain ongoing.  However, the import logic is generally able to import 
everything from an official or custom (EOF-created) pro guitar MIDI track as 
expected.  Exported pro guitar tracks work in the current beta of Phase Shift.  
That leaves the following tasks:

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).

Also:
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.

Original comment by raynebc on 23 Jan 2011 at 5:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by raynebc on 27 Jan 2011 at 12:40

[GoogleCodeExporter]

17. Improve the editor logic so that if an existing note is edited by 
adding/removing a gem to a lane, that note is automatically selected.  Writing 
a function that sets the eof_selection structure as if a note had been 
individually selected may by useful.

18. Improve the editor logic so that if notes are pasted, eof_selection is 
updated to reflect the first of those notes as being selected, using logic from 
a function that may have been created for task #17.  This will allow notes to 
be pasted and the N keyboard shortcut to be used to immediately edit the 
newly-pasted notes.  Currently, a paste operation leaves eof_selection to 
reflect no note selected when a paste is carried out.

Original comment by raynebc on 30 Jan 2011 at 8:38

[GoogleCodeExporter]

thekiwimaddog pointed out that the slide detection logic isn't correct in at 
least "Space Oddity", in that the slides in the solo beginning at 3:37 and the 
single slide at 4:37 are in the wrong direction.  I looked at the note 103 
markers, but they always seem to use a velocity matching the highest used 
string in the note/chord, which doesn't indicate which direction the slide 
should go.

Original comment by raynebc on 11 Feb 2011 at 12:00

[GoogleCodeExporter]

I proposed custom marker notation for slides (as per issue 196) to 
thekiwimaddog.  If he agrees, we can implement slides this way until the 
"official" method to denote them is determined.

19.  Add a dialog for defining a guitar's tuning.  thekiwimaddog and I haven't 
agreed yet on how to implement a tuning INI tag.  He'd prefer each string's 
tuning be defined relative to standard tuning, and I'd prefer each string's 
tuning to be defined as the absolute note value.
20.  Add a chord name database.  This would be a musically-correct database of 
standard chords (like Cmaj) and which musical notes combine to form them.  I 
have proposed some initial program logic for how the lookup would work in this 
post:
http://www.fretsonfire.net/forums/viewtopic.php?f=1&t=50349&p=586821#p586821
This would be a convenient feature for users to have, so they wouldn't have to 
manually name chords.

Original comment by raynebc on 2 May 2011 at 7:53

[GoogleCodeExporter]

Regarding task 19, I am inquiring about the tuning definition on ScoreHero, 
where people may have uncovered RB3's native method of defining a song's tuning:
http://rockband.scorehero.com/forum/viewtopic.php?p=630537#630537

Original comment by raynebc on 8 May 2011 at 10:24

[GoogleCodeExporter]

r763 adds logic to write generic root notes for pro guitar tracks during MIDI 
export.  When the chord lookup logic is completed, MIDI export should lookup 
each chord and write the appropriate chord root notes:

Any derivation of E chord = 4
Any derivation of F chord = 5
Any derivation of Bb chord = 6
Any derivation of G chord = 7
Any derivation of Ab chord = 8
Any derivation of A chord = 9
Any derivation of Bb chord = 10
Any derivation of B chord = 11
Any derivation of C chord = 12
Any derivation of Db chord = 13
Any derivation of D chord = 14
Any derivation of Eb chord = 15

Original comment by raynebc on 22 May 2011 at 6:05

[GoogleCodeExporter]

Somebody on ScoreHero confirmed that each song's DTA file has a line that 
defines the tuning for bass and guitar, ie Drop D tuning for guitar:
real_guitar_tuning (-2 0 0 0 0 0)

Whereas pro bass uses "real_bass_tuning" instead.  I will propose to 
thekiwimaddog that we use the same INI tag definitions.

Original comment by raynebc on 24 May 2011 at 7:40

[GoogleCodeExporter]

r764 adds some initial tuning logic.

Original comment by raynebc on 27 May 2011 at 8:46

[GoogleCodeExporter]

r767 nearly completes the tuning logic.  Import and export support for the 
tuning tags still needs to be added.  I'm emailing thekiwimaddog to finalize 
our tuning string standard, which I'm proposing to be:

real_guitar_tuning # # # # # # "[b]Tuning name here[/b]"
real_bass_tuning # [...] # "[b]Tuning name here[/b]"

Original comment by raynebc on 29 May 2011 at 9:39

[GoogleCodeExporter]

21.  Add "pull off" pro guitar note import/export support.  I haven't 
determined how these are marked in RB3 MIDIs yet, I'll have to find a chart 
that uses it.

Original comment by raynebc on 29 May 2011 at 9:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I proposed to thekiwimaddog that we use a custom phrase marker to define custom 
note names, since they would have to be difficulty specific:

(Sysex event ID)
(Sysex message length)
'P','S','\0'
# (difficulty)
11 (Custom note name)
"note name here" (This would be a NULL terminated string, so strcpy could be 
used to read the string into a buffer)
0xF7 (End of Sysex)

Original comment by raynebc on 29 May 2011 at 7:53

[GoogleCodeExporter]

When the chord lookup logic is done, it may be necessary to check to see if 
dynamically lookup up the name of a chord slows down screen rendering too much. 
 If so, the looked up name could be cached in the note name string.  This would 
require some changes to the handling of note names so that manually added note 
names are permanent (until manually changed), whereas dynamically created names 
are updated every time the chord was edited.  For example:

name[0] == '\0' if the note has no manual/dynamic name
name[0] is alphanumerical character if it was manually defined
name[0] is not alphanumerical and is not '\0' if it was dynamically defined

Instances where name[0] was checked (and when eof_get_note_name() was used) 
would need to be updated to also check the first character with isalpha() to 
determine if the note name was defined.  Save routines would need to skip 
writing dynamic names, display routines would need to render name[1] instead of 
name[0] for dynamic names, after editing a note, etc.

Original comment by raynebc on 29 May 2011 at 9:49

[GoogleCodeExporter]

I changed the proposed tuning tag format to:

real_guitar_tuning = # # # # # # "Tuning name here"
real_bass_tuning = # [...] # "Tuning name here"

Original comment by raynebc on 29 May 2011 at 10:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

r768 completes task 19 by adding INI import/export for the tuning tag.  That 
leaves the following tasks:

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.
17. Improve the editor logic so that if an existing note is edited by 
adding/removing a gem to a lane, that note is automatically selected.  Writing 
a function that sets the eof_selection structure as if a note had been 
individually selected may by useful.
18. Improve the editor logic so that if notes are pasted, eof_selection is 
updated to reflect the first of those notes as being selected, using logic from 
a function that may have been created for task #17.  This will allow notes to 
be pasted and the N keyboard shortcut to be used to immediately edit the 
newly-pasted notes.  Currently, a paste operation leaves eof_selection to 
reflect no note selected when a paste is carried out.
20.  Add a chord name database.  This would be a musically-correct database of 
standard chords (like Cmaj) and which musical notes combine to form them.  I 
have proposed some initial program logic for how the lookup would work in this 
post:
http://www.fretsonfire.net/forums/viewtopic.php?f=1&t=50349&p=586821#p586821
This would be a convenient feature for users to have, so they wouldn't have to 
manually name chords.
21.  Add "pull off" pro guitar note import/export support.  I haven't 
determined how these are marked in RB3 MIDIs yet, so in the mean time, custom 
phrase markers for MIDI import/export (as per the specifications in issue 196) 
can be used.

Also:
22.  Implement custom phrase markers for MIDI import/export (as per the 
specifications in issue 196) for up/down slides and palm mutes.
23.  Change the custom note name import/export logic to use custom note names 
(as per the specifications in issue 196).
24.  When task 20 is completed, update the root note export logic to write 
appropriate note numbers as per the details in comment 35.
25.  Add the ability to mark vibratos and bends, using custom phrase markers 
for MIDI import/export (as per the specifications in issue 196).

Original comment by raynebc on 29 May 2011 at 10:57

[GoogleCodeExporter]

26.  Add the ability to define the number of strings in use for the pro bass 
track.  Currently 6 strings are enforced.  This wouldn't be a problem except 
the default tuning is different depending on whether the pro bass track is 4 
strings, 5 strings of 6 strings.  The pro guitar track rendering will need to 
be updated to respect the number of strings in use (if necessary), and there 
should be a check function that sees if any gems would be lost due to lowering 
the number of strings on the pro bass track and warns the user with a prompt 
before dropping affected gems and changing the number of strings.  During MIDI 
import, the highest used string number will be tracked for pro bass.  INI 
import would need to be changed to automatically set the number of strings 
based on an existing pro bass tuning tag, and a check would need to be 
performed to see if any imported notes used a higher string than what the 
tuning tag defines.  If there is a conflict between the MIDI and the tuning 
tag, the user would need to be warned about the error and the tuning tag will 
be ignored.

If there is no pro bass tuning tag (or the tag was ignored due to an error as 
described above), 4 strings with default tuning should be assumed unless the 
MIDI has gems for string 5, in which case 5 strings with default tuning should 
be assumed unless the MIDI has gems for string 6, in which case 6 strings with 
default tuning should be assumed.

Original comment by raynebc on 29 May 2011 at 11:15

[GoogleCodeExporter]

r769 completes task 26 and allows the number of strings for pro guitar and bass 
to be set to 4, 5 or 6.

Original comment by raynebc on 30 May 2011 at 9:31

[GoogleCodeExporter]

Regarding issue 20, I've decided it won't be feasible to maintain a text 
database of over 150 chords, so I'm going to use music theory to look them up 
the traditional way (intervals of major scales).

Original comment by raynebc on 30 May 2011 at 11:41

[GoogleCodeExporter]

r771 begins issue 20 by defining 12 different chords (major, minor, diminished, 
augmented, major 6th, minor 6th, 7th, major 7th, minor 7th, 7th with flat 
fifth, 7th with sharp fifth, diminished 7th) and logic to match each chord in 
each of the 12 major scales.

Regarding the rest of task 20, the new logic is flexible enough that it should 
be easy to define other chord types such as for power chords, I'll just need to 
find a more exhaustive list of chords.  Slash chords, however, are going to 
require more logic.

Original comment by raynebc on 31 May 2011 at 9:58

[GoogleCodeExporter]

r772 brings the chord definition count to 18 per scale.

I'm going to consider task 20 completed, meaning I can now work on task 24.  
The root note just defines which scale the chord is in, and the conversion 
between my note system (0 is A) and RB3's (4 is E, 9 is A, 15 is Eb) can be 
accomplished with this formula:

(scale + 9) % 16 + (4 * ((scale + 9) / 16))

I previously made a typo in comment 35.  Root note 6 represents chords in the 
Gb major scale.  It remains to be seen if there is a special root note to 
indicate that a chord is not a named chord in any major scale.  If the chord 
lookup doesn't find a match, I might try having the root note omitted during 
MIDI export and seeing if Magma complains about it.  If it does, I'd need to 
find a RB3 chart that has non-named chords in the Expert track, so I can see 
how those chords' root notes are marked.

Original comment by raynebc on 1 Jun 2011 at 8:07