klearnnotes2-devel

[kln2-devel] updates-clefs

[Mo <Mo...@no...>]

Hello all

I've been assigned to add new clefs: Treble and Alto. I have been slow
in doing this (C++ is new to me, but mostly, I am lacking time to work
on this project due to personal life obligations).

Just wanted to update all of you: I made recent changes:

I re-name method setClefTreble to setClefByAction and got rid of
setClefTreble. 

Changes were made to klearnnotes2.h and klearnnotes2.cpp.

I'm still working on elaborating the new method, btw.
Thanks!
-Mo

[kln2-devel] solfege recap

[Mo <Mo...@no...>]

Hello Klearnnotes team :)


Sorry for the delayed response but I wanted to make some comments on
this e-mail.

Personally, in my opinion, learning the names of notes is the start of
musical anaylsis and theory. From there, the student can move on to
scales, minor and major keys, key signatures, chords and their
inversions, and so on.

It has become apparent to me, however, there are differences in some
locations in the world on how this is dones. In some places, letter
names are dominant while in others, solfege is the norm. 
Solfege however, does come with its set of problems mostly due to the
fact that (1) there are two different variations of it and (2) there are
some issues in determining how to label a raised or lowered note in the
Fixed Do method.

However, looking ahead:

Say in the future we decide to add some non-traditional scales into our
program For example... 

whole tone scale:
C D E F# G# A#

Diminished Scale
C D Eb F F# G# A B

Blues Scale
C Eb F (F#) G Bb

Can either Solfege methods work in these cases without confusing the
user? For example, in Fixed Do, do we sing Fa for F and F# but label the
notes as Fa and Fa#? 

I'm not even sure if Movable Do would even work in these odd scales.
Mainly due to the reason in that there is no tonal center in some of
these scales and Movable is based on assigning Do to the root/tonic
note.

> Just to restate the problem:
> 1. we need Solfeggio, because apparently this main method of naming notes
>   in some parts of the world (not because it is easier to be sung)

Okay, I didn't realize this. This is new to me :)

> 2. movable Do doesn't solve (1.) because it is not used there (and would
>   teach people things their folks would not understand)

Yes, I do realize not everybody uses Movable Do. Just as I find Fixed Do
confusing at times, I can see how the reverse can be true.

> 3. fixed Do is ambiguous (see bellow).

The great advantage that Fixed Do has over Moveable Do is that one does
not need to know what key the music is in. 

Somebody posted this link: http://en.wikipedia.org/wiki/Solfege
And I will quote from it: 

"the disadvantage [of Movable Do] is that the singer must do a harmonic
analysis of the piece in order to sing the correct syllables. In fixed
Do, the pitches are set: the tonic, Do, is C, Re is D, and so on; Fa is
easy to remember, since it is F."


> 2. Similar problem: we have to test if an user remembers the key signature
> in the following part of the score. OK, we have G Major key signature. Now
> there is a F note in the score. "Dear user, what is the name of this
> note?". Well, if we don't distinguish Fa and Fa# we cannot test if the
> user remembers that key signature applies to this note.

I see the problem. If we ask the user to write a G Major scale, should
we expect a "Fa#" or "Fa"? If we are testing for correct musical
anaylsis, I would think Fa# would be correct. But if the user is singing
the note, then Fa would be correct.


> > If so, why are we even bothering using solfege at all?
> 
> Because the guys repored, that in their environment naming notes by single
> letters is virtually not used. They use Do/Re/Mi for everything: naming
> notes, scales, pieces of music.

Ok, I didn't know about this either :)
The guys are going to have the best input on this on how this system
works for them in their environments. 

Marek has come up with some good ideas on how to resolve issues
pertaining to some of the issues of Fixed Do. I feel fine with his
resolutions. We should take into consideration however, with some issues
that could come up such as unusual scales, decorated chords, etc.

-Mo

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

Re: [kln2-devel] development environment

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

On Sun, 7 Mar 2004, Fernando Cuenca wrote:
> In a nutshell: is there any particular IDE I should be using? or should I
> just go and change the Makefiles manually?

Edit Makefile.am-s manually.

BTW, I made some corrections to the files, and it should work fine now (in
1.1 release after editing Makefile.am, .moc* were not created). Please
report if this introduced any new problems.

> I also noticed there is a .pro file

This one is used for generating translations (see po/i18n_howto).

> I saw what it looks like a kdevelop project file,

This is how things started. Kept "just in case", but it is very much not
up to date.

~Marek

-- 

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

[kln2-devel] development environment

[Fernando C. <fer...@ya...>]

Hi,

Something I forgot to ask in my previous e-mail: what development
environment are you using to maintain the code? I saw what it looks like a
kdevelop project file, but is not for the version I have (2.1). I also
noticed there is a .pro file I could open with Qt Designer.

In a nutshell: is there any particular IDE I should be using? or should I
just go and change the Makefiles manually?

Thanks.

Saludos!
Fernando.


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

[kln2-devel] Solfeggio notation design proposal

[Fernando C. <fer...@ya...>]

Hi all,

My name is Fernando Cuenca and I have been entrusted to implement the
Solfeggio (aka Do-Re-Mi) notation in KLearnNotes. I have been looking at
the code and I'd like to share some design ideas on how to implement the
new functionality.

Since I'm new to this group, though, let me introduce myself first. I'm
originary from Cordoba, Argentina but I'm now living in Toronto, Canada,
where I work for a software development company. I studied music throught
all my chilhood and the piano for a few years in my late teens (I'm 32
now). I have recently decided to restart my piano playing, but I realized
that if I want this attempt to be lasting I need to improve the skill that
prompted me to abandon it years ago: my sight-reading (it really sucks
:-). In any case, that's how I came across KLearnNotes.

Now, to the Do-Re-Mi issue: as far as I could see by scanning through the
code, currently the notes are stored in the orderOfNotes global char array
(declared in klearnnotes2.h). That array is used in several places, mainly
to get the note name (which usually is put into a QString object); in
other cases, is used to get the ascii value associated with the note.

What I'm planning to do is to replace that array with a new class, which
will provide for both kinds of access (QString and int) and a notation
switching mechanism:

   class ScaleNotation
   {
    public:
       // ... other declarations...

       enum ScaleNote { evB = 0, evA, evG, evF, evE, evD, evC }

       QString GetNote(ScaleNote) const;
       int     GetNote(ScaleNote) const;

       static const ScaleNotation* GetCurrentNotation();
       static void SwitchNotation(ScaleNotation*);
   };

In a first pass, I will refactor all the existing code to use this class
(which will be a Singleton, to provide a unique, globally accessible
instance). I'll commit this change to CVS, so everybody else can start
working with this instead of the global array. Later, I will add the GUI
components, for which I will need some guidance, since I don't have
experience with Qt/KDE development.

Well, that's the idea. Any comments will be appreciated.

Saludos!
Fernando.



__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

[kln2-devel] PianoKeyboard,NameButtonsBox,BaseMusicNote

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

Hi e-body.

I just wanted to let you all know, that I did some major changes
in the kln2. Parts which have already been there were almost not
modified, so what you are working on should be little affected
(although will have to be modified in future to get full
advantage of the changes). Please, report any problems.

===========================

First of all, I included a new class BaseMusicNote. This holds
many static functions for conversion of e.g. a form with
note+accidental to midi pitch, returning number of the note in
octave (0 for ANY C, 1 for ANY C# or Db and so on), returning
QString of a note name dependent on "enum Notation {English,
German}" and things like this. Extra methods of this kind will
have to be added in future. Please, for any such a conversion
needed, add a new method into BaseMusicNote.

I think we needed such an abstraction of a music note. Current
'Note' class is too much connected to staff canvas picture. And
many abstract note properties were scattered all through the
code.

==========================

Another change affects the structure of the code very much. Now,
let's think about future exercises. They re-use the same kinds
of widgets.

Example:
There is now a note-to-name exercise : you see a note in the
staff, and you choose it's name from namebuttons.

But there will be e.g. note-to-fret exercise : you see a note in
the staff (so the staff canvas is used again) and you should
find an appropriate PieceOfFret (a one-note place on the fretboard).

And there may be a fret-to-name exercise: you see a PieceOfFret
highlighted (fretboard reused) and should choose appropriate
namebutton (namebuttons reused).

Basically, what I am trying to say is : there will be only few
different elements just used in different configurations. In the
form in which it is written now it would be quite hard to
implement. The nameButtons, the staff canvas etc. are direct
properties of KLearnNotes2 class. Therefore, their
initialization makes the code quite complicated (anybody who
read KLearnNotes2 constructor knows, it takes a pen and a big
piece of paper to figure out which layout corresponds to which
widgets and where it is placed in the main window). This makes
any modifications quite complicated. Plus, all the elements have
to know about each other: did you noticed, that one of arguments
of ClickableView constructor is ...  KLearnNotes2* ??? And it
runs KLearnNotes2 class methods directly!  (grep for
"papcio->isStarted()"). I guess this is one of the best
candidates for the bottle of wine contest (do you remember my
introductory kln2-devel e-mail? :) .

Nope, that's not the way things should be done.
* All self contained elements should be extracted into separate
  classes (NameButtonBox, Staff, PianoKeyboard, GuitarFretboard
  etc.).
* They should not run each other methods directly; rather, they
  should emit signals informing about what an user is doing and let
  the exercise setup decide how to react on this (that is, to
  which slots of which objects connect these signals).

OK. So I did it for the two simplest examples: PianoKeyboard and
NameButtonBox. I also added examples of these to the
KLearnNotes2 constructor, so that you could see how they are
used (see the attached screenshot). I DO NOT INTEND TO KEEP THEM
DISPLAYED THIS WAY. This is added temporarily just to show you
what's new.

What to look at?
First of all, look at the end of KLearnNotes2 constructor. The
PianoKeyboard and NameButtonBox are created, added and set up
(signals are connected to some slots) just in few lines of code!
What a difference compared to the complicated setup of the old
buttons/canvas ! Basically, everything that deals with placement
of buttons/piano keys (="everything messy") is done in the
PianoKeyboard and NameButtonBox classes.

Second thing: you will see in standard output info about all
signals emitted (just click on the piano keys/nameButtons). As
you see, they are much more detailed than what is really used
right now, so more detailed user action handling will be quite
easy too.

And the third thing: new files musicwidget.{h,cpp} and
modifications of KLNfancywidgets.{h,cpp} are examples of usage
of BaseMusicNote class.

==========================

This is the very crude first version of the new classes. If you
look at the code you will see that many methods are not written
yet (they are just "{}"). RandomObject stuff should be handled
within the classes.  Also, I didn't write comments for all the
methods/members yet.

~Marek

PS: For those with slow i-net connection: updating
    Makefile.am  basemusicnote.cpp  klearnnotes2.cpp  musicwidget.h
    Makefile.in  basemusicnote.h    musicwidget.cpp
    KLNcanvasitems.cpp KLNcanvasitems.h KLNfancywidgets.cpp
    KLNfancywidgets.h globals.h
and, because of recent Mo's commits:
    klearnnotes2.h
in src/ should be enough.

-- 

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

Re: [kln2-devel] Solfege questions...

[<oxy...@ya...>]

Yes, I really know what are you talking about. I took
a semester of solfege in Mexico. But that system was
explained to us in the first day only, and we used the
fixed one. The moveable one is used to learn solfege
in the contries that uses the A B C system, like here
in Canada.

Maybe we can use the system on the game in the future
when the microphone input is working already and as
Instrument: voice option, but by now is not a good
idea.

Remember that klearnnotes is for learn to read music,
not to learn to sing.

Javier

_________________________________________________________
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Re: [kln2-devel] re: do-re-mi

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

On Thu, 4 Mar 2004, Mo wrote:
> I hate to beat the subject into the ground but I do think we should look
> beyond our group and decide what is best for our users.

OK. The problem is, that kln2 is fairly new program so solutions like:

> Or can we set up a poll on the homepage and let people vote for a
> determined period of time?

simply would not work. And I'm not sure if it is clear for us what we
would ask about in the poll (I mean, what the choice really is).

> Are we going to implement this soon?

Yeah, why not? It doesn't seem as too much work. If Fernando will have
time to do this fast - great, if not, someone else can do this. This is
really not much work. :) And most of this involves moving from using one
char to a QString - it does not depend on which Solfeggio convention is
used.

And, anyway, the most important question always is where are we aiming,
not in what order etc. So: what is the perfect final goal?

> I wrote up an elaborate e-mail explaining this system [...]
> I'm not sure if I send it now

Sure. Send it.

Just to restate the problem:
1. we need Solfeggio, because apparently this main method of naming notes
  in some parts of the world (not because it is easier to be sung)
2. movable Do doesn't solve (1.) because it is not used there (and would
  teach people things their folks would not understand)
3. fixed Do is ambiguous (see bellow).

> Is this Solfege system suggesting an *altered* Fixed Do method?

OK, OK. This needs clarifying:

> The Fixed Do system assigns the Solfege words to specific notes. The
> note "C" will alway be "Do". The note "D" will always be "Re".

Yes. So as long as there are no sharps/flats there is no problem.

> But say you have a "C#" ... in the Fixed Do system it will still assing
> "Do" to this note.

OK. But this introduces a confusion, I guess.

1. In one of his letters, Fernando suggested that the same convention is
also used for scale naming. You can call both C and C# "Do" when you see a
note in a staff. But now imagine a name-to-scale exercise. Give an user a
task, say "put appropriate number of accidentals to build up a key
signature 'Do major'". Now, how to hell the user is to figure out if she
is to put no accidentals (for C Major) or 7 sharps (for C# Major)?

2. Similar problem: we have to test if an user remembers the key signature
in the following part of the score. OK, we have G Major key signature. Now
there is a F note in the score. "Dear user, what is the name of this
note?". Well, if we don't distinguish Fa and Fa# we cannot test if the
user remembers that key signature applies to this note.

I guess, this is why the "modified Fixed Do" appeared in the discussion.

I mean, what to do about it? I think, we have to distinguish F from F#
(right?). If fixed Do doesn't do this and people have never seen anything
like Fi what else, apart from introducing "Fa#" can we do?

> ******************
> MOVABLE DO SYSTEM
> Written Solfege:
> DOb REb MIb FAb SOLb LAb TIb
>
> Sung Solfege:
> "dough flat" "ray flat" "me flat" "fa flat" "sol flat" "la flat" tea
> flat"
> *******************

:D Yep, that's the problem I meant when in one of previous e-mails I voted
for movable Do.

> Can I repeat myself here? The Solfege method was developed with intent
> of being sung. Singing an "A flat minor" scale and pronouncing each
> "flat" is not really smooth.

OK. But I suppose, we can assume that users are not complete morons. There
is a distinction between what you say/sing and what you recognize. If we
write
	Do, Do#, Re
it doesn't mean you have to sing "do, do-sharp,ray". You would rather sing
"Do,Do,Re" but REMEMBER that the second Do has a sharp. (OK, some users
will get caught in this trap - so what to do about it? Would a clear
helpfile stressing this point do?).

I mean, after all we will force users to make some mouse clicks, right?
Even if you use fixed Do you are aware that sometimes "Do" means C#.
What we would do by introducing "Do#" string would be like saying "it's
Do, but it has a sharp". Is it really different from what you THINK when
you use fixed Do?

> If so, why are we even bothering using solfege at all? We might
> as well sing A minor like this:
>
> A Flat - B Flat - C Flat - D Flat - E Flat ....

Yep. In the US - maybe. ;)

> If so, why are we even bothering using solfege at all?

Because the guys repored, that in their environment naming notes by single
letters is virtually not used. They use Do/Re/Mi for everything: naming
notes, scales, pieces of music.

Just to summarize:
* fixed Do seems too limited to be used for all kinds of questions
* movable Do is great; theoretically :( ; there is no point in forcing
  users to learn things nobody around them would understand
* fixed Do can be very simply modified by adding a #/b sign after note's
  name; it's up to a user if she pronounces it; nevertheless, everybody
  using fixed Do has this modification in their minds - you do remember if
  by saying "Re" you mean "D", "D#" or "Db".

Therefore I believe, adding a sharp/flat sign to indicate what you mean by
"Re" is not that great of unorthodoxy. Would it be really confusing?

So I suggest that the aim (and choice for users) would be four kinds of
note's names:
* English (one letter, with A-B-C)
* German  (one letter, with A-H-C)
* modified Fixed Do ( Do-Do#-Re with an explanation in docs: "Do#" is to
  be sung "Do", just remember it has a sharp)
* Movable Do (Do-Di-Re).

And, yes, I agree. We have to clarify this. No discussion is closed until
we find a satisfactory solution.

~Marek

-- 

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

[kln2-devel] Solfege questions...

[Mo <Mo...@no...>]

> 
> On Wed, 3 Mar 2004, Silhusk wrote:
> > I agree, personally I didn't even know about the existence of the
> > Do-Ti-Te stuff!
> 
> OK. It is Fernando, Javier and Carlo against Mo. The case is closed:
> we stick to Do-Do#/Reb-Re stuff for now.
> 
> Mo, if you think Do-Di/Ra-Re is useful it can be coded in future, but
> even then Do-Do#/Reb-Re should be left as a default Solfeggio.
> 

I hate to beat the subject into the ground but I do think we should look
beyond our group and decide what is best for our users. Are we going to
implement this soon? Or can we set up a poll on the homepage and let
people vote for a determined period of time?

I have a feeling that maybe some of you may not completely understand
the Moveable Do system that I am suggesting. I wrote up an elaborate
e-mail explaining this system the other day but could not send it due to
e-mail problems. I'm not sure if I send it now if it would make a
difference or not. Let me know if you guys want me to try and resend it.
It might clear up some confusion on it(?). I don't know at this point.

On the other hand...I have never seen Solfege sung as some of you are
suggesting. So, I will be honest here and admit I don't completely
understand the method we have decided on so far. Is this Solfege system
suggesting an *altered* Fixed Do method? 

The Fixed Do system assigns the Solfege words to specific notes. The
note "C" will alway be "Do". The note "D" will always be "Re". But say
you have a "C#" ... in the Fixed Do system it will still assing "Do" to
this note. 

(These examples are written and sung as follows)
***************
The Fixed Do example (first three notes of scale):
C Major Scale: Do Re Mi
C Minor Scale: Do Re Mi

G Major Scale: Sol La Ti
G Major Scale: Sol La Ti

A Flat Minor Scale: La Ti Do Re Mi Fa Sol 
********************
********************
The Moveable Do system in contrast will assign "Do" to the root note. 
(First three notes of Scale)
C major scale: Do Re Mi
C minor scale: Do Re Me

G Major Scale: Do Re Mi
G Minor Scale: Do Re Me

A Flat Minor scale: Do Re Me Fa Sol La Te 
********************

On the other hand, the Solfege method that others are presenting here
made no indication if it is a movable system or a fixed system. This is
important to make this clear since it will have an effect on how we
implement this. Remeber, I have no experience in the suggested Solfege
method and I don't want to make assumptions.

Also, remember that Solfege was meant to be sung. The system was
developed by a Monk in the 11th(?) Century to teach people to
sight-sing. So with that in mind, are we suggesting that a "A Flat Minor
Natural Scale" is sung like this?

(Using the proposed "approved" method to the best of my understanding
but yet undefined if it is a MOVABLE or FIXED system.)

******************
MOVABLE DO SYSTEM
Written Solfege:
DOb REb MIb FAb SOLb LAb TIb

Sung Solfege:
"dough flat" "ray flat" "me flat" "fa flat" "sol flat" "la flat" tea
flat"
*******************
*******************
FIXED DO SYSTEM
Written Solfege:
LAb TIb DOb REb MIb FAb SOLb

Sung Solfege:
"la flat" "tea flat" "dough flat" "ray flat" "me flat" "fa flat" "sol
flat"
*******************

Can I repeat myself here? The Solfege method was developed with intent
of being sung. Singing an "A flat minor" scale and pronouncing each
"flat" is not really smooth. 

I could be way off in my understanding of our approved method. I could
be understand the whole proposed method wrong.

On the other hand, it seems that since we are going in this direction
for now, I really want to make this clear. Right now I am confused
because we are introducing "flats and sharps" into the solfege
vocabulary and that is something that I have not seen before. Nobody has
indicated if this was a Fixed or Movable Do System. And does one really
pronouce the words "sharp and flat" while singing in solfege in this
system? If so, why are we even bothering using solfege at all? We might
as well sing A minor like this:

A Flat - B Flat - C Flat - D Flat - E Flat ....



Thanks!!!
>From a confused Mo :)

Re: [kln2-devel] re: do-re-mi

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

On Wed, 3 Mar 2004, Silhusk wrote:
> I agree, personally I didn't even know about the existence of the
> Do-Ti-Te stuff!

OK. It is Fernando, Javier and Carlo against Mo. The case is closed:
we stick to Do-Do#/Reb-Re stuff for now.

Mo, if you think Do-Di/Ra-Re is useful it can be coded in future, but
even then Do-Do#/Reb-Re should be left as a default Solfeggio.

> The idea of a user-editable config file is great, but we should provide
> pre-configured files for most notations.

Sure. :)

> What about a wizard to
> let the user chose the notation from a complete list with descriptions
> (also geographical), and let him chose also the input method
> (fretboard/keyboard)?

We'll see. Anyway, I think this should NOT (!) be solved by translations -
any user should be able to train any notation system, even if it seems
not to fit to his language.

For now we have three or four notes' names conventions - it can be
handled by a simple menu. In future, if other things will be
geography-dependent we can think about such a wizard dialog.

~Marek

-- 

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

[kln2-devel] Qt configure problems

[<oxy...@ya...>]

Marek:

[root@linux]# apt-get install qt
Reading Package Lists... Done
Building Dependency Tree... Done
qt is already the newest version.
0 packages upgraded, 0 newly installed, 0 removed and
0 not upgraded.
[root@linux]# locate libqt-mt.so.3
/usr/lib/qt-3.1/lib/libqt-mt.so.3
/usr/lib/qt-3.1/lib/libqt-mt.so.3.1
/usr/lib/qt-3.1/lib/libqt-mt.so.3.1.2
[root@linux]# rpm -qf
/usr/lib/qt-3.1/lib/libqt-mt.so.3.1.2
qt-3.1.2-14
[root@linux]# /usr/bin/kde-config --prefix
/usr/bin/kde-config: error while loading shared
libraries: libqt-mt.so.3: cannot open shared object
file: No such file or director


My system is apt based (Planetccrma) I only need the
name of the rpm to install it.

Thanks, Marek


_________________________________________________________
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Re: [kln2-devel] Re: qcanvas and configure problems

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

Javier,

On Tue, 2 Mar 2004, [iso-8859-1] javier wrote:
> /usr/bin/kde-config: error while loading shared libraries:
> libqt-mt.so.3: cannot open shared object file: No such file or directory

There are two kinds of qt libraries: with and without "multi thread" (mt)
support. You need the mt version.

On my comp "locate libqt-mt.so.3" gives (among other lines)

/usr/lib/qt-3.0.3/lib/libqt-mt.so.3.0.3

and "rpm -qf /usr/lib/qt-3.0.3/lib/libqt-mt.so.3.0.3" says "qt-3.0.3-11".
So maybe you have non-mt version of Qt? Note, that at least on my computer
libqt-mt.so.3 is part of mutli thread Qt, not Qt-devel.

Anyway, you should be able to run kde-config from command line. On my
computer '/usr/bin/kde-config --prefix' gives

/usr


> --------------------------------------------------------

I really like your idea of the game. :)

> level 1-3 treble clef

But, please, please, in the beginning focus only on this. Make the game
work on treble clef (and forget about grand staff for a while), without
changing any graphics. I believe, you can do this quite quickly. :)

Please: KISS. _K_eep _I_t _S_uuuuper _S_imple. Small steps - this is the
only way to progress!

You said, you have no experience with Qt. This way you will learn how
things are used in this library, get some experience, so working in future
on the grand staff (both treble and bass clefs on the same page) will be
easier. If you jump right now into this you may spend enormous amount of
time, and do something that doesn't really fit other parts of the program
(so your grand staff may be hard to use for other exercises etc.).

Let me say it again: please focus now on making the game work on treble
clef, and treat this as an occasion to get familiar with kln2 source.

~Marek

-- 

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

Re: [kln2-devel] re: do-re-mi

[Silhusk <si...@bl...>]

Hi,


> The notation that is used in the rest of the world is
> DO-DO#/REb-RE-RE#/MIb-MI-FA-FA#/SOLb-SOL-SOL#/LAb-LA-LA#/SIb-
> SI, even the singing guys use it.

I agree, personally I didn't even know about the existence of the
Do-Ti-Te stuff! (I found some info at
http://en.wikipedia.org/wiki/Solfege )

The idea of a user-editable config file is great, but we should provide
pre-configured files for most notations. Otherwise the user would have
to write his own config file before starting to learn notes. Anyway, how
can the user know wich notation he should learn? What about a wizard to
let the user chose the notation from a complete list with descriptions
(also geographical), and let him chose also the input method
(fretboard/keyboard)?



BTW: I speak/write italian, english, french and (some way) german; no
spanish, sorry...

regards,
Carlo

Re: [kln2-devel] Re: qcanvas and configure problems

[<oxy...@ya...>]

here is the full output of configure. ???? Attachment
1.

I am happy to see that is some work done already and
will the time shorter to finish the game.

this is how will work the game:

level 1-3 treble clef
level 4-6 bass clef
level 7 treble + bass clef
level 8-9 tenor clef
level 10 all clefs

The background will be the same, second attachment,
exept for the tenor clef, when will be only this clef
in the middle C, in black and the bass and treble,
shaded.

--------------------------------------------------------
--------------------------------------------------------
treble--------------------------------------------------
--------------------------------------------------------
--------------------------------------------------------
- - - - - - - - - - - - - - - - - - - - - - - - - - -
-
--------------------------------------------------------
--------------------------------------------------------
bass----------------------------------------------------
--------------------------------------------------------
--------------------------------------------------------


--------------------------------------------------------
--------------------------------------------------------
(treble)------------------------------------------------
--------------------------------------------------------
--------------------------------------------------------
Tenor- - - - - - - - - - - - - - - - - - - - - - - - -
-
--------------------------------------------------------
--------------------------------------------------------
(bass)--------------------------------------------------
--------------------------------------------------------
--------------------------------------------------------

also the third attachment is the way I want the game,
with a Hummingbird that is controlled by the user and
ballons instead of notes. That will make it way too
diferent from noteattack and even the original
Hummingbird.

What do you think?

_________________________________________________________
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

[kln2-devel] Re: qcanvas and configure problems

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

On Mon, 1 Mar 2004, javier wrote:
> Also I decided to use Qcanvas for the game. Anyone
> have experience in this library?

Javier,

The notes, staff and lines are already now displayed in QCanvas.
The lines are inherited from QCanvasLines, Note inherits
QCanvasEllipse and clefs are basically QCanvasRectangles, and
so on.

This is much simpler than what it looks like. :) I will send you
some suggestions in a moment.

> Here is an attachment text file with my last
> ./configure.
> Some devel stuff must be missing.

? Is it the full file? It seems to be truncated. The last line
of what you sent is checking for meinproc... /usr/bin/meinproc
and no line above this one seems to report a problem.

On my computer after the 'meinproc' line there are few more:

===========
checking for meinproc... /usr/bin/meinproc
checking whether byte ordering is bigendian... no
checking for MAXPATHLEN... 4096
checking if doc should be compiled... yes
checking if po should be compiled... yes
checking if src should be compiled... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating doc/en/Makefile
config.status: creating doc/HTML/Makefile
config.status: creating doc/px/Makefile
config.status: creating po/Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
Good - your configure finished. Start make now
===========

Do you get anything like this?

~Marek

-- 

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

Re: [kln2-devel] re: do-re-mi

[<oxy...@ya...>]

The notation that is used in the rest of the world is
DO-DO#/REb-RE-RE#/MIb-MI-FA-FA#/SOLb-SOL-SOL#/LAb-LA-LA#/SIb-
SI, even the singing guys use it.

Also I decided to use Qcanvas for the game. Anyone
have experience in this library?

Here is an attachment text file with my last
./configure.
Some devel stuff must be missing. 

Cheers!!

_________________________________________________________
Do You Yahoo!?
La mejor conexión a internet y 25MB extra a tu correo por $100 al mes. http://net.yahoo.com.mx

Re: [kln2-devel] re: do-re-mi

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

Hi e-body,

On Sun, 29 Feb 2004 16:12:59 Fernando Cuenca wrote:
> > My suggestion would be adding it as a third option for
> > German/English notation (I guess "French notation" is an
> > adequate name for do-re-mi stuff).
>
> What about calling it "Italian" or "Latin"? According to the
> legend, the names come from:
>
>   _Ut_ queant laxis  (eventually became "do")
>   _Re_sonare fibris
>   _Mi_ra gestorum
>   _Fa_muli tuorum
>   _Sol_ve pulluti
>   _La_bii reatum
>   _S_ancte _J_ohannes (eventually became "si" or "ti")

Wow, I just wanted to learn about music, and now I am picking up
Latin... :)

After reading Mo's letter: I would stick to "Solfeggio" name for
this - it is probably less confusing. Or we may simply call this
"Do-Re-Mi notation".

> We could use "Ti" for "si", which is what English speakers use
> ("si" gets confused with "C"). In that case, all notes would
> have a unique letter:
>
>    [d]o
>    [r]e
>    [m]i
>    [f]a
>    [s]ol
>    [l]a
>    [t]i
>
> I haven't looked at the code yet, but I would assume the
> keystrokes associated with each letter are kind of hard-coded
> now, aren't they? In that case, we also need to find a way of
> generalizing that.

First of all: they do change when you change notation from
English to German (the first one reacts on computer kbd key "B" the
other on "H"). And there is another kbd input way: you can press
number keys displayed above the buttons (3 for C, 4 for D and so
on). So they are not that 'hard' coded. ;)

> > How do you call these? E.g. what is C#? "Do sharp"? "Do with
> > a cross"?
>
> In English, it would be "Do sharp" or "Mi flat". In Spanish, "Do
> sostenido" or "Mi bemol".
>
> > Is it clear what "Do #" might mean?
>
> Yes. We use the "#" sign for sharps and "b" for flat,
> following the name (like "Do#" or "Mib").
>
> > how are chords like "C sharp major" called?
>
> In Spanish you use capital M for Mayor and lower case m for
> minor. Like in: "Do# Mayor" and "Mib minor". Also, if you
> don't mention the mode (like in just "Do#") it's assumed you
> are refering to the Major mode.

The reason I asked was that in Poland do-re-mi is
sometimes used but I have never ever seen it with any
accidental.

On Mon, 01 Mar 2004 Mo wrote:
> Ascending:
> Do Di Re Ri Mi Fa Fi Sol Si La Li Ti Do
>
> Descending
> Do Ti Te La Le Sol Se Fa Mi Me Re Ra Do



[Sigh.] Fernadno's and Mo's letters are a bit contradictory. So
"Di" or "Do #"? "Te" or "Ti b"?

I like Se-Sol-Si more than "Sol b - Sol - Sol #" (because it is
more concise and can be used for singing) but the question is
which is more frequently used. Could you, guys sort this out
between yourselves and let us know about the conclusion?

In the end there are two contradictory directions:
* a user should have a choice
* a user should get a clear interface (therefore, 30 different
  notation options are not acceptable).

So, I would choose one of those (my vote goes for
Do-Ti-Te/Li-La-Le/Si-Sol-Se/Fi-Fa-Mi-Me/Ri-Re-Ra/Di-Do), and
store it e.g. in a user-editable config file. Does this seem
reasonable?

~Marek

-- 

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

[kln2-devel] cvs policy

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

Fernando,

> About CVS, do you have any branching and/or check-in
> policy I should be aware of?

Actually everybody but me is new to the project. People started
working on things and there are already some commits, but there
is no clear CVS policy so far.

Please, commit only versions that compile (otherwise you would
disturb anyone who works on a separate task). Also errors in
administrative files (e.g. Makefiles) may lead to some
hard-to-predict problems, so I would rather be the only person
who commits changes to them.

Once these requirement is fulfilled - commit as often as
possible. Even if not everything is implemented or doesn't do
what it is supposed to do yet. This way
1. people can follow others work and adjust what they do;
2. if few people change the same file small changes are merged
   better.

Once you get an idea what you want to change, I suggest that you
share with others on kln2-devel (see my e-mail on key signatures
as an example). Especially, that your work will overlap a bit
with work of others (for example Jim is working on name-to-note
exercise which deals a lot with buttons).

~Marek

-- 

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

[kln2-devel] spanish, os x

[Mo <Mo...@no...>]

> If Mo have OSX, that could help to attract more
> programmers, so maybe a binary for apple computers is
> a good idea.

Yes, I have OS X. Though its been several weeks since I have booted up
my Mac. I am enjoying the transition to Linux :)

> Somebody else speaks spanish?

I can. Well...sort of. I can understand it better than speak it. My mom
talks to me all the time in spanish.

-Mo

[kln2-devel] re: do-re-mi

[Mo <Mo...@no...>]

> > In Poland we call C sharp "C#" or "cis". I don't really know how
> > to extend "do-re-mi" system to accidented notes. Maybe this
> > should be kept only for preliminary lessons, without
> > accidentals, and not extended for features planned in future?

The Do-Re-Mi method (Solfeggio) is great and has its place in
musicianship. One will find this used in sight-singing of melodies
without text.

There are several methods of the Do systems:

THE FIXED Do:

Notes C,D,E,F,G,A and B are mapped to Do, Re, Mi, Fa, Sol, La, and Ti.
The name for each note is sung without any regards to accidentals.
For example, in the G major key, Sol is G while F# is Fa.

THE MOVEABLE Do:

In this method, Do always represents the tonic or first degree of the 
scale, regardless of accidental. For example, in the G major key, Do is
G while Ti is F#. The chromatic scale is as follows in this method:
Ascending:
Do Di Re Ri Mi Fa Fi Sol Si La Li Ti Do

Descending
Do Ti Te La Le Sol Se Fa Mi Me Re Ra Do


Personally, I have learned the Movable Do system and that seems to be
the predominant method here in the USA. Although I have had professors
in the Universities that have used the Fixed Do method primarily. 

At the moment KLearnnotes2 is aimed at learning notes. We don't have to
stop here however. Learning notes is very basic part of theroy. There
has been discussion of including key signatures which is great. Learning
chords and their different inversions would be nice as well. Even better
yet, introducing tempo and sequence of notes would be awesome. Have the
application plays very simple intervals of notes and the student would
select the correct notes and place it on the clef. Later it could be
extended into playing simple melodies with varying rhythm and tempo.
Again here, the application will play a tune. The student then has to
listen and then place the correct notes on the clef.

The latter part is where the Solfegio system will help a student. Right
now, learning notes does not require a sense of tonality, intervals,
scales, or different keys. If we introduce intervals and keys, and
extend it as I written above, the Solfeggio system would work nicely.
Personally I have found the Moveable Do system easy to learn and it
gives the student a sense of tonality. We should not however abandon the
actual names of notes. 

If we decide to go in this direction, introducing melodies and rhythm,
it will turn our application from learning music theory into a
musicianship application. 

[kln2-devel] timidity support

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

Hi e-body,

On Thu, 26 Feb 2004, javier wrote:
> Here is a timidity++ info:
> http://www.onicos.com/staff/iz/timidity/doc/oss-hack.htm

OK, using this file (with some minor changes) I added timidity
support. For me it works.

You can select it from the sound setup dialog.

Note, that new classes were introduced. It should be fairly
easy to include other sound output ways now. If anybody is
interested (and for example would like to add ALSA support?)-
see, how it is done for OSS vs timidity (doxygen docs are
already generated).

Problems:
1. Maybe it's only my midi patch bank, but guitar sounds are
  terrible. Piano is OK (but still much worse than OSS stuff).
2. Maybe it's only my midi patch bank, but very low notes make
  ... very high sounds. Try the bass clef - only few top notes
  make reasonable sounds.
3. Some new compile time warnings. It compiles for me, but
  please check if the new CVS version compiles on your systems.
4. The kind of selected midi output method is not saved. Until
  it's done you will have to run sound setup dialog each time if
  you want to use timidity.
5. The volume of first timidity sounds is much too big. Then,
  somehow it normalizes...
6. You may need to select timidity TWICE; it takes extra time
  to start the server for the first time (I guess just leaving
  some time after starting the server would be enough). On the
  other hand there is too much of timidity server starting/
  stopping (it should be started once, I suppose).
7. You can't use Voice Recognition together with timidity sounds
  (I don't think this could be helped).
8. Sometimes switching back to OSS (and hitting 'TEST') causes
  a crash. I'm not sure what is the reason.

If anyone notices any other problem, please report. Any
suggestions welcome.

~Marek

PS. I also corrected some minor errors in OSS/Free sound setup.
For example quite absurd WhatIs for number of Channels QSpinBox
in midi_setup dialog. Plans: add short device info and make
the dialog aware of number of available devices.

-- 

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

[kln2-devel] Do-Re-Mi

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

Hi e-body,

Three people independently requested the same feature, and
Fernando even declared he wants to look at this. Great. :)

There are some questions about accidentals, though. Please
look below at what I sent to Fernando. Any comments?

~Marek

On Fri, 16 Jan 2004 javierpulido@canada... wrote:
>  I think that we have to keep A B C notation and maybe
> add a french one Do-Re-Mi later. What do you think?.

On Tue, 17 Feb 2004, Silhusk wrote:
> in italian notes are usually named
> Do Re Mi Fa Sol La Si instead of
> C  D  E  F  G   A  B
> could be possible to have them also translated? (on namebuttons)

On Sun, 29 Feb 2004, Marek Wieckowski wrote:
> On Sat, 28 Feb 2004, Fernando Cuenca wrote:
> > However, my musical training has always been with note names (do, re,
> > mi, ...) instead of letters,
> ...
> > I can try to implement that feature.
>
> Great!
...
> My suggestion would be adding it as a third option for
> German/English notation (I guess "French notation" is an
> adequate name for do-re-mi stuff). But I warn you that this
> would be quite some work because of two reasons:
> 1. this would require changing current toggle-style into
>  multiple choice - like for speed-goal levels
>  (Prentice/Jman/Wizard)
> 2. this would change the way notes are named from char to, e.g.
>  QString.
> Plus there would be different way how to recognize that an user
> answered right (she can't press "do" key on the kbd, can she? first
> letter: D for do, R for re etc.? what about sol-si?).
>
>
>
> For future: how do you call notes with accidentals (sharp/cross
> "#" or flat/bemol "b")? These will be needed e.g. for the guitar
> fretboard and key signature/scale recognition. How do you call
> these? E.g. what is C#? "Do sharp"? "Do with a cross"? Is it
> clear what "Do #" might mean? When you see a song book for
> guitar players (with chords' names above lyrics/text) how are
> chords like "C sharp major" called? Or, for example, what is the
> name of Chopin's Prelude opus 45? Or Shostakovitch's Violin
> Concerto No.2 Op. 129?
>
> In Poland we call C sharp "C#" or "cis". I don't really know how
> to extend "do-re-mi" system to accidented notes. Maybe this
> should be kept only for preliminary lessons, without
> accidentals, and not extended for features planned in future?

[kln2-devel] Re: KLearnNotes2-devel digest, Vol 1 #10 - 2 msgs

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

Javier,

On Tue, 24 Feb 2004 javier wrote:
> I suggest to use alt+C for Cb and ctrl+C for C#.

OK, I guess an user should have a choice.

I have to look at how Qt handles keys. Does pressing Ctrl itself send a
signal? Does it handle keys raw or does it look at xmodmap stuff (e.g.
does it tell Alt_L form Mode_switch etc.)?

> And using an fretboard instead of the keyboard image
> will convert all the guitar players of the world
> potencial users

Yes, sure. The fretboard is the main focus now. :)

> (piano players know already to read music).

But the point was quite different: even if you are a guitar player seeing
e.g. connection of a key signature to a scale is much clearer on a piano
keyboard. That's why at some point piano kbd should be there too. But I
agree: NOT for the price of slowing down work on the fretboard.

~Marek


---------- Forwarded message ----------
Date: Tue, 24 Feb 2004 13:45:16 -0600 (CST)
From: "[iso-8859-1] javier" <oxy_amigo@yahoo...
Reply-To: javierpulido@canada...
To: Marek Wieckowski <Marek.Wieckowski@fuw...
Subject: Re: [kln2-devel] Re: KLearnNotes2-devel digest, Vol 1 #10 - 2 msgs

I suggest to use alt+C for Cb and ctrl+C for C#.
And using an fretboard instead of the keyboard image
will convert all the guitar players of the world
potencial users (piano players know already to read
music).

I have ADSL now and I still have problems compiling
from the command prompt. What are the requeriments? I
have upgrade my fedora system and still stock in a
library from aRts, but I have it installed.

If Mo have OSX, that could help to attract more
programmers, so maybe a binary for apple computers is
a good idea.

Somebody else speaks spanish?

cheers!
Javier

_________________________________________________________
Do You Yahoo!?
La mejor conexi=F3n a internet y 25MB extra a tu correo por $100 al mes. ht=
tp://net.yahoo.com.mx

[kln2-devel] midi output

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

Hi e-body,

On Mon, 23 Feb 2004, Mo wrote:
>   "DEBUG: midi_turnOn(): couldn't open midi device!"
>Although I have ALSA working on my computer. What else am I missing?

Mo, it's not you, it's kln2 that is missing something. :( It uses
OSS/Free, because this is what I have, and this is what I could test.

Remarks below do not end with anything constructive, so if you are not
interested just ignore them. This is just to let you imagine where I am
with thinking about the problem.

==============================================

Yes, there are different ways of generating (midi) sounds and users should
have a choice.

A good source for implementing different solutions is for example
'solfege'. They have there:
* OSS (/dev/sequencer , /dev/sequencer2 == /dev/music)
        sorted out better than what I have written based on very raw code
* external programs:
        timidity -idqq %s
        drvmidi -i d %s
        playmidi -f %s
(although the last two would work only with OSS, I believe). Plus, they
use some properties of python which look almost like overriding virtual
C++ members, so maybe even part of the structure of the (quite clear and
extensible :) code could be preserved.

Timidity is very popular and works for virtually everyone, so this is
probably the solution we need fast (Javier voted for this quite some time
ago). And it should be very easy to implement (based on e.g. solfege). So,
this may happen soon.

ALSA? How? (maybe see how old 'rosegarden' uses it)

Another solution would be to use some library which would take care of
different hardware and sound libs.

        libkmid
is the most obvious choice (but I wasn't able to implement it; on the
other hand I spent on this very little time; Mo: does kmid program play
midi files on your computer?). And making use of aRts (instead of
suspending it, as it is done now) would be nice. BTW: is there a gnome
equivalent?

        allegro
?

        jackd
? (see how new 'rosegarden' uses it)

BTW, right now the only SF kln2 programming "help wanted" post is about
this problem. So maybe someone experienced with the subject will still
volunteer.

================================================

Conclusion: one day (let's hope soon) someone will have to look at this.
For now, sorry, midi will not work for you. From kln2 point of view it is
not that important. Please, try to ignore the problem. :(

~Marek

-- 

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