Recent Changes - Search:


Upgrades

This page does not desribe the current implementation. It was a draft used for discussion. Parts of it has been implemented.

Tom E, can you described your idea about upgrading, and what the gui should do? (I'm assuming you are thinking about the topic directoy implementation.)

The 'problem' to be handled on upgrades are that the statistics and test results has to be deleted when the lesson file change. Sometimes the change to the lesson file is of such a nature that this is not necessary, but finding a failsafe solution to this is not easy.

Let me give it a try (it's premature)

Solfege sorts the lessonfile by name to give them a level-number. So a topicdirectory with 4 lessonfiles could look like this:

  100 do-re-mi 
  200 do-re-mi-fa
  300 do-re-mi-fa-sol
  400 do-re-mi-fa-sol-la

After pupils have run the exercises, and solfege has stored their scores, the teacher may change his mind and add/change/remove some files.

At runtime, solfege uses stored md5 sums to see which exercises have changed since the last program start. For each exercise that has changed, solfege will store a notice in the test results. This enables solfege (and the teacher) to put the scores for an older and a newer version 'into one box'. This will only work if the filename (including the number-prefix) has not changed. So if the teacher wants to make a new scorelist, he simply changes the number and/or name.

  50 do-re
  100 do-re-mi
  150 do-re-mi-fast
  200 do-re-mi-fa ( <- unchanged file)
  400 do-re-mi-fa-sol-la ( <- changed file, for example the tempo is made slower)
  • removing lessonfiles (file 300 do-re-mi-fa-sol). solfege keeps the scores but they won't be updated any more because the lessonfile won't be run again. (At runtime, the number of subsequent levels change, but that doesn't do anything to the scores)
  • adding lessonfiles (files 50 and 150). solfege makes the scores (At runtime, the number of subsequent the levels change, but that doesn't do anything to the scores)
  • changing lessonfiles. solfege runs the md5 check and discovers that file 400 do-re-mi-fa-sol-la has changed. Solfege adds a mark in the score log. the exercise and score will continue to work as before.

Now after this change/add/delete of lessonfiles, solfege must be able to tell which exercises are (considered) completed by the pupil; so that she doesn't have to start from level 1 again. (note: there is no need for this when an autodidact is working with solfege; however, the system could still be used as a level advisory). Each lessonfile defines what it takes to complete it (see the {test} block). Solfege simply compares the statistics of every lessonfile with the conditions in the {test} block. The completed file with the highest level (=the highest sorted filename) will be used as point of reference. All lower exercise levels are considered completed, and solfege will put the user in the first subsequent level.

Discussion on the obsolete topic file implementation

Upgrades to newer versions of Solfege topic files must be handled at least as well as lesson files are handled today.

What happends with the users stored data about is practising if a topic file changed? What if a new level is inserted into the topic file? What if a level is changed?

I've been thinking about a system. Such problems could be handled easier by a gui interface than by a system based on textfiles.

I'm hoping to avoid any gui. A gui means that the user has to descide on something. What we are doing with statistics for lesson files today, is that if the lesson file has changed, then the statistics for that lesson file is lost. Since we will follow your idea with a topic directly, things will be easier to handle than the a topic file.
Good point. Let's try to stick with the no-topic-file principle.

<< Statistics and test results | NewExerciseSetup | Remarks >>

Edit - History - Print - Recent Changes - Search
Page last modified on April 23, 2005, at 09:48 PM