
**************************************
******************* IN VERSION 1.2
**************************************

========
BASED ON a new NotesGroup Class
========
Class NotesGroup
{
	int type;	//0=individual notes, 1=sliders/ranges
	bool rememberClef;
	QString title;	//"name" @ combo
	int minrange;
	int maxrange;
	bool notenames[7];	// name checkboxes remembered
	char clef;	// T/B
	bool aNote* notes[MaxAll];// neither bool nor *  good for saving... 
	//			maybe extract a struct 'savableData' ?
------------------
	set...()
	get...()
	update() // setup notes based on ranges etc.
}

==========
NotesGroup* allExercises[];	// saving: first number of exes, then appended
	// exe by exe into one file 

NotesGroup* currentNotes;      // always saved on exit (even if not part of
	//                        remembered combo-exes
	

========
1.  individual testnotes selection and individually auto-design test

	+ a button "Make custom exercise" (which
	  should set both proper notes/ranges and speed goals)
	  based on after-test statistics

	+ exe suggestion

	+ maybe an extra dialog "custom exe editor"

	+ a 'select notes for test' state: 
		-all notes visible
		-click selects/deselects
	  or maybe: rightclick selects/deselects?
		-voice adds/removes (a moving frame needed - otherwise: which 
			'C' did user mean???)

2. custom exe added to "Exercise" combobox in the toolbox and saved/restored
	+ an option: "remember cleff"


=======
COMPLETELY NEW EXERCISES' IDEAS  but based on similar interface:
=======
3. add exercise in another direction with all testnotes visible:

INI:
* all testnotes reset and visible
* not-so-random name choice: note, that it should also know about nubmer
	of notes of a given name (really????? if one doesn't know a note
	and makes mistakes this note will be repeated anyway; if one 
	answers right and fast the fact, that the note is rare should not
	matter)
* one namebutton highlighted; clock starts

ANSWER CHECK:
-> click a note	-> if it's already maked (non-black colored) - NOP
		|
		-> otherwise:
			stop clock
			-> if it's right name OK++, change note's color 2 green
			|
			-> if wrong, WR++, change it to red...
		|
		loop through all testnotes: 
			-> if exists black of the name wait for next click
			|
			-> otherwise reset and draw a new question
======
4. add exercise in another direction with no testnotes visible
	- like (1.) but without testnotes shown

this would require splitting the range into octaves:
CDEFGAHCDEFGAHCDEFGAHCDEFGA
<-----><-----><-----><---->
   <-----><-----><----->

aNote* octaves[7][8];
                  ^ how many 1/2-separation octaves may fit into the staff?
int numOctaves=0;
int numNotesInOctave[8];
int octaveFill=0;
for(i=minRange; i<maxRange ; i++)
	octaveFill++; // octave should be shifted after 7 notes
			// no matter how many of them were added
        if(octaveFill==8)
                octaveFill=0
                numOctaves++
                if(numOctaves is even)
			i-=3;
		else
			i-=4;

       if(aNote[i] is active)
		octaves[noteNumber][numOctaves]==aNote[i];
		numNotesInOctave[numOctaves]++;

if(numNotesInOctave[numOctave]<2) numOctave--;
	// there range ecceded last octave, but, even after an 'i'
	// back shift there were either no o 1 activenote in the last
	// octave - don't use it for draws

if(numOctave<1) =>  bail out
	NOTE: for ==1 there should be no octave-draw



The rest goes in a standard way:
* we random-draw an octave and change color of a region of the staff
* we random-draw a sequence of notes within an octave

question=button lit
answer=click in the staff (maybe an animation: a note going down/up to the
	right position)



**************************************
******************* IN VERSION 2.0
**************************************

NEW INTERFACE EXERCISES :

*************************************************
***(sharps, flats, exe based not-on-notes) ******
*************************************************
* extra notes and extra buttons
* new class: accidentals or sharps/flats
* exercises from 1.X in a manually choosen key

class Sharp -> like aNote, different picture
class Flat  -> like aNote, different picture

orderOfSharps[];
orderOfFlats[];

class Key
{ int numSharps;
  int numFlats;
  aNote* majorTonicNote;
  aNote* minorTonicNote;
  show()
	{ allOff();
	for(i<numSharps)
		sharp[orderofSharps[i]]->show()
	or the same for flats
	}

accidented notes: two possibilities
	* features of standard notes (each note can be sharp/flat or natural)
		- good because C and C# will not be visible the same time
	* 3 sets of notes: natural/sharp/flat
		- good for random draw
I think I like the second idea better - each note can still hold a pointer
	to its sharpen/flatten version

Now, notes have to be aware of cleff key signature: each would be displayed
	differently depending on a key. If there already is # by the cleff,
	F# would be displayed as just a round note (_); otherwise it would 
	picute as #(_) (a note with a sharp in front);
note, that also natural notes have to know the cleff key signature (to know
	if they should display 'natural' in front)


=======
1. teach key signatures

=======
2. teach major/minor chords writing in staff & recognition

=======
3. design somehow common interface to all kinds of exercises

=======
4. theory help (what is the order of sharps/flats etc.)

	* Add helpers for keys when key signature exercise will be there
	* either major OR minor keys in one test
	* intervals: in C-key first with explicit accidentals

**************************************
********* (fretboard/keyborard) ******
**************************************

* both as an input for answers and as a question field

Note that fretboard can be included even before there are accidented
notes: simply not all field on the fretboard would be activatable; with
a keyboard it is even easier!

Keyboard is also easier, because each note is there only once.

A step-by step for fretboard:
1) just frist 4 frets and natural notes active
	* fretboard as an answering device (instead of buttons)

2) add a reorganizer: questions can be asked by buttons, staff or fretboard,
	and answer all three ways too
there can even be a fretboard-to-fretboard exercise!
	* fretboard as a question

Fretboard has FIELDS and divided into vertical frets and horizontal strings.

a Field can be 	*off (grayed)
		*on  (normal)
		*activated (maybe: with extra-bold string
			    maybe: with highilighted bg
			    maybe: with notes' name in the center)
					^^^^^^^^^^^ flat or sharp???

maybe aNote should have:
	* a picture in the staff
	* a pointer to its namebutton
	* all pointers to all fret fields (btw. - this way a field can get to
		all it's equivalents too!)

for notes selection it would be best if all three: the staff, namebuttons
and fretboard or keyboard fit into one window (it is quite possible)
- changing ranges/checkboxes would turn fields on/off

Again: first test it without accidentals (some fields permanently disabled).


**************************************
********* voice control         ******
**************************************

* add extra notes
* maybe: add a box steered by voice "up" "down" "left" "right"
	- this would enable voice select answer on a fretboard
* the same idea may be used for notes/buttons selection

**************************************
**************************************
**************************************
**************************************
**************************************
**************************************
******************* IDEAS POSTPONED TO MAYBE-NEVER
**************************************

===================  TIMING of QUESTIONS/ training for speed =======
1. decreasing time of pauses between questions and leave only limited
	(and decreasing) time for an answer

questions have to vanish after a timeout; otherwise a user can answer slowly,
and there is no motivation for speeding

to make pauses shorter and shorter, and notes vanish:
LOOP
question -> show -> start a regular timer

1-> growtime; if time not too big time++
		if time too big hide question, say too_long 
		* another note's parameter: numTooLong -
		  should make note more frequent, but not force-scheduled
=> check (printInDebug) onetimes before erasing (is 1st really so big; why?
 	what eats up the time?)
2-> answer; checkanswer etc. 

count-down rather then time spent on 1 question;
maybe: onetime--  would be clearer (in the code) than onetime++?

maybe: part of checkanswer and overtime could be outsourced to another
	function
maybe: add another togglebutton: progressive time (each questions the
	time4answer gets 0.5% shorter; this means after 140 questions 
	you have about half the time: (0.995)^140=0.496
	NO: see extra exe-type combo idea below!
if one sets up a speedgoal we start with 2x longer questions and after
	140 questions we are there;
if one is not able to answer that fast time is increased; 
if one makes too many mistakes either time is increaserd or user is turned
	to no-time-limit exercises;
then one can train with a steady speed;
(again: an automatic after-test personal new test suggestions would be
	desirable;
	maybe even whole course:
	0. introductory, no-times-limit tests to train notes names
	only then we start training for speed:
	1. program remembers your answering speed from no-time-limit tests
	   - this is a starting point for few time-regression tests 
	2. when maximum user's speed is settled there is a series of
	   fixed speed and regression speed tests; is there speed progress?
	3. this is done until the user achieves his speed goal
	or
	3'. if user slows down because of particular notes or errs about 
	   particular notes a special forced test can be prepared
)
possible modification: a test without errors - user has to eventually
answer right (clicking a wrong answer would simply slow down answering speed)

Speeding up should make both time for answer and pauses between questions
shorter. A comments window seems inevitable; a list of QStrings + listview?

Timing might be calculated each time based on number of right/wrong answers
and times or based on previous speed; The first way should be preferred (this
way the program can e.g. gauge speed on the slowest answered note speed);
Note: each note needs, apart from overall speed, a last-answer speed - let
us hope, the user would make some progress.

Maybe a forced question: each 5 question the slowest not is chosen; then
user gets: once a question about this note, once about a random from others.
Statusbar should display current test mode. Another combo and menu with
list of tests
* choose a note tests [IN FUTURE: 1.2]
* no-time-limit test (make a reminder that one should first play with
	notes/buttons and remember correspondence)
* low speed exercises
* speed progression exercises
* keep-high-speed exercises (come back to this one once a while; if you
	can't do it go back to the speed-progression)
One variable: speedProgress
* = -1 	=> no time limit
* = 0  	=> no speed change
* = 1	=> progression by a factor 0.995 after each in-time answer
		maybe: wiser choice based on individual notes' speeds
		maybe: the slowest note most important
		time the user has should never be shorter then 1.2* time
	       of his fastest answer; we don't want a mission impossible tests!

Remember user statistics for each exercise in -/.kln.

Because there would be no sequence, t->hide should be run by nextnote() 
(rather then redraw).

maybe: only few runs and easy goals for all levels except from 10/20/30/40
(with all notes in particular range)? at least make such suggestion in 
helpfiels

	* wrong answer should slow things down (i.e. make pauses longer)

	maybe: the faster user does the shorter pauses? this would add
	  some dynamics (right now (1.0) due to long pauses between
	  questions, tests go in steady pace even for fast-answering user
	  which doesn't encourage speeding :( )


=======
2. add sequence reading exercise: 

new display necessery: x-positions of notes;
let's assume that no note can be repeated in a sequence: number of aNotes
will not have to change

NO: in future one may need a sequenc-of-chords exercise; in such a case
a note on the same line can need to be displayed twice; it may be
better to make already here a matrix of notes: each note has few (4-5)
copies of different x-positions; maybe new class: sameNotes
(because some features,e.g. midi pitches may be outsorced; if one would
like to use shared (static?) properties one would have to distinguish
between different notes heights anyway...


x-position step: 5*SC
because if note's are shifted (moveit-ed) they take 2*SC to the left/right
from central position

new param.LOS: defLengthOfStaff = number of notes that can fit into the staff

aNote* questions[defLOS]

LOOP:
--> choose aNote ("normal" wise random) into questions[] untill filled
|
|   numAns=0
|   while(numAns++<defLOS)
|	answer	-> show CORRECT answer under the staff in red or green
|
|   show some stats about a series
|   if numQue not too big loopback (choose a new sequence)
\--/


=======
3. idea (2.) the other way around:
