Re: [kln2-devel] Solfeggio notation design proposal

[Marek W. <Mar...@fu...>]

Fernando,

I tried to design some common note handling interface by defining a
BaseMusicNote class (see src/basemusicnote.{cpp,h}). This has a drawback,
that some things are right now done twice in different way in v1.1 code
and in different way in the new widgets setup.

Maybe you could already now add your new code to the BaseMusicNote class
(directly within the class or by making it accessible there) and
implement BaseMusicNote usage in other parts of the code? This would
simplify future work on kln2 (things would be done using just one, common
note handling interface).

On Sun, 7 Mar 2004, Fernando Cuenca wrote:
> orderOfNotes global char array. That array is used
[...]
> to get the note name ;
[...]
> to get the ascii value associated with the note.

So the first of the above points is used to display note's name in the
staff (when highlighted) and on buttons. "Ti" or "H" or "B".

Now, the second thing is quite tricky, because it is also used to
react on user input (through keyboard). And this has to change
when notation changes ('T' or 'H' or 'B'). How to do this? Note that for
accidentals we need shift and ctrl or shift and alt handling too.

One character stuff is enough for v1.1 exercises without accidentals, but
we need to think about how it can be extended.

>        QString GetNote(ScaleNote) const;

Grrrrr. There are too many "notes". No one will be able to guess what
"getting a note" means. Call it more explicitly, maybe:
        QString getStringNameOfNote(ScaleNote) const;
or
        QString getStringName(ScaleNote) const;

BTW. please, keep capital first letter reserved for class/types names
only.

>        int     GetNote(ScaleNote) const;
What is this one to return? ASCII char? How will it be extended to
accidented notes? This is probably a question of where this method is
meant to be used: probably the ASCII char is now used both for identifying
a note (e.g. when defining a MIDI pich step for a treble or bass clef
notes) and for checking keyboard input :(.

One way:
one method returning a number or char of the base name (0 or 'C' or 'D'
for any C,C#,Cb, 1 or 'D' or 'R' for any D,D#,Db), and the second
returning accidental (1 for C#,D# etc, 0 for C, D etc. -1 for Cb, Db).
Nice for identifying a note. For keyboard input maybe one QKeySequence?
	getKeySequence(ScaleNote)
Maybe both?

AND/OR:
a method returning a BaseMusicNote* (example of note of this name). This
has an advantage of possibility to define for BaseMusicNote
* a function 'bool nameMatches (BaseMusicNote*, BaseMusicNote*)'
	true for an C# (e.g. one octave higher)
* a function 'bool pitchMatches (BaseMusicNote*, BaseMusicNote*)'
	true for any note of the same pitch (e.g. C# and Db)
* a == operator for (which would be true if both pitch and name match).
and use all the methods of the BaseMusicNote. Plus some methods like
	BaseMusicNote::getKeySequence()


OR:
maybe keep the features of ScaleNotation within BaseMusicNote rather than
separate class? Both have advantages and disadvantages. Keeping a separate
ScaleNotation may or may not make the code cleaner. It is easier to
implement in v1.1 part code (one global array changed to your Singleton).
On the other hand, keeping things self-contained within BaseMusicNote
properties and methods doesn't sound that bad either. Look at how
NameButtonsBox sets up its buttons compared to the v1.1 buttons.

> Later, I will add the GUI components

OK. What would these be? Change of behavior of "German/English notation"
menu item, right? Anything else?

~Marek

-- 

     \/   /|\  Marek Wieckowski
  #####  | | |
 = . . =  \|/  Institute of Theoretical Physics
    U      |   Warsaw University
  / ~ \___ |
 <|   |    |
  > . <    |   http://www.fuw.edu.pl/~wiecko
 <<___>>   |   http://klearnnotes2.sourceforge.net