   The KSynth tasklist:
   ~~~~~~~~~~~~~~~~~~~~

KSynth is not yet ready for public use - you know that. But perhaps you
would like to help, but you don't have an idea what is needed. It might
be that you don't have skills in C++ or Qt-programming, or whatever.

I have created a list of tasks that I think are important for the
project to evolve fast. If you like, pick a task that interests you
and contact me...

1. tasks which do not require programming skills:
-------------------------------------------------

  - A better name for the project could be nice

     If you know one, contact me

  - We need a nice homepage (graphics/design!)

     The stuff I hacked together is not quite what a homepage could be.
     What I specially think of are a news ticker, perhaps with database,
     so that people can watch how the project evolves.

                                       (this is currently being worked on)

  - Tutorials for KSynth would be nice!

     For that you'll have to experiment a little, to be then able to
     show people how they actually can get nice sounds of of KSynth.

     Perhaps it would be good if those were sgml or html or something
     that everyone can view.

  - Examples for KSynth

     Same direction as the tutorials. People need to see that it's
     really a capable program!

  - Online Help

     Yes, every KDE program needs online help, so needs KSynth. AFAIK
     this has to be sgml to be KDE compliant ;)

  - Module normalization

     This one is quite a large task. But certainly interesting as well
     as challenging.

     The point is: we have about ten modules now. We'll need perhaps
     fifty or so, for the thing to be really useful. These have to be
     catigorized and sorted, described and written.

     What is specially important is that they follow the same concept.
     For instance it makes no sense, if some modules require frequencies
     to be specified as 1/f, others need them to be given as f.

     Another (challenging!!) point is, that every module should be able
     to be plugged to every other without the possibility that some values
     go out of the required ranges for playing them.

     For instance a module just adding two signals might be a bad idea,
     because if one signal is between -1 and 1 and the other as well,
     output will be between -2 and 2. If you have play modules which only
     accept the range between -1 and 1, the output will break.

     A better idea would be a module mixing the two signals, sig1 at a level
     of x percent, sig2 at a level of (100-x) percent.

     Then the output will stay between -1 and 1 in any case, if the input
     wasn't broken before.

     Currently not everything is so clean, so you can get broken output if
     you mix the modules wrong. (And some accept ranges between 0 and 1,
     while others accept ranges between -1 and 1, which is _not_ the way
     it should work).

     It will help for that task if you can write own modules (you only need
     a little C++), but it is certainly not required.

2. tasks which do require programming/scripting skills:
-------------------------------------------------------

  - configure stuff/KDE compliance

     This is almost usable already now, just needs a little fine tuning:

     It would be cool if ksynth just ran and installed out of the box with
     "./configure ; make ; make install". It should autodetect mico and
     which C-Compiler, and which sound system (while currently only linux/oss
     is supported), and later perhaps whether to build a KDE gui or run 
     with what-ever-else-gui.

     .kdelnk, icons, internationalization, online help. All that should
     install without problems.

  - plugins

     Think about how the GUI and the synthesis system could be extended at
     runtime with dynamically loading plugins. There is something in
     koffice2, don't know if it's usable for that though.

     Specifically for the synthesizer we can't afford performance loss
     while scheduling ;)

  - midi bus

     How can KSynth and the rest of the world communicate? How can the
     midi events be routed? I am currently thinking about that as well,
     and perhaps building a lightweight solution soon. In any case this
     has to be discussed in public (on the corresponding kde lists), to
     get things compatible later.

     BTW: I will not focus on making KSynth (and the midi bus and the like)
     a KDE only project, but it's currently the fastest way for me to get
     things really working and usable. I want to MAKE MUSIC with that stuff
     soon and not design around two years ;)

  - gui builder

     This is a challenging part as well. We need something that shows whats
     going on - and of course all those buttons where one can tune around
     to modify the sound. Perhaps we can reuse something from koffice here
     as well, to get "components", which simply can be plugged in runtime.

     Nothing is done there yet.

  - performance tuning

     Everything that makes things go faster is welcome. You'll need to
     experiment, profile and think a little here. One approach might be
     to calculate multiple cycles at one time, this makes scheduling
     overhead go down. But this is not always possible (short delays and
     feedback are not calculatable that way.

  - XML saving (or something else)

     Yes, we could need another fileformat - using KConfig to save the
     structures will certainly not be the best thing (specially when it
     comes to embedding sample data or what ever in the file).

  - module writing

     This is close to the module normalization (see above). We need that...
     now, because without modules which are cool and work together like a
     dream KSynth has no value.

     You will only need a little knowledge about how to program (C or C++),
     since modules which mix two sampling streams or delay audio data tend to
     be simple. ;)

Cu... Stefan <stefan@space.twc.de>
