- fix problems with REGISTER_IMPLEMENTATION:
  => sometimes, global constructors don't work, so we'd better get rid
     of them entierly ; instead, an init function needs to be added to
     dynamically loaded modules
- get rid of all error handling done by assert ; thus, one by one review
  each assert if it can happen under any circumstances if yes, it needs
  to be replaced by some other mechanism
- report errors properly if some component could not be loaded ; right
  now, it fails within assert(skel) in generated code, which doesn't
  help users much to debug the problem
- VERSION-INFO for modules?
- md5auth isn't initialized properly in conjunction with ARTS_SERVER
- make it possible to use C API and C++ API together
- FIXME: what to do about apps which are not threaded but nevertheless
  want to use the engine?
- gsl: rounding should be used even for unsigned conversions

## MCOP Core Infrastructure

- offer sampleprecise timing
- resource management (i.e. locate resources like "samples" or "structures"
  in a similar uniform way KDE does with KStandardDirs)
- check why adding thousand non-running objects degrades scheduling
  performance quite a lot
- recursive scheduling again (with loops & cycles)
- obsoleting: use V2 implementations even if user requests a normal
  implementation, since they have a newer version
- error notification for connection breaks - this would enable intelligent
  clients to immediately know when something goes wrong, so they can terminate
  sanely instead of crashing
- mcopidl: use unsigned char arrays instead of strings for inline marshalled
  data in idl files - this will fix the "maximum string length" warnings and
  while doing this improve space and speed
- try to clean up notification manager, code generation and _copy() _release()
  style referencing across functions in notification and Dispatcher - the
  alternatives seem to be even more automatic referencing magic, or freeing
  objects only if the stack is empty (idle freeing)
- fix generated code for struct Foo { object bar; }
- fix fallback into higher namespaces, the following idl file should be accepted
  module A { interface Z; module B { interface Y : Z { }; }; };

- debugging: if two alternating messages are emitted, the message compression
  doesn't work, and the user will be flooded with debugging message, the X
  server will crash, and so on - a possible strategy would be:
   * make an always present MCOP object which can receive confirmations from
     artsmessage
   * start artsmessage as usual, but tell it about the MCOP object, so that
     artsmessage can
	   - tell the MCOP object if it is done
	   - query the MCOP object for the repetition count of the message
   * queue repeated messages as long as they are still visible on screen

## aRts SoundServer

- export configuration interfaces from the soundserver (so that
  you can see and change the autosuspend timeout for instance)
- support multiple artsd instances on one computer (like multiple displays),
  and think of a clever way to register them
- more support for different audio input/output methods (i.e. SDL)
- support channels != 2
- expand capabilities of shell utils (making them eventually as powerful as
  artscontrol, or better ;)
- make it possible to share a cookie between multiple hosts (like storing it
  in nfs mounted home directory)
- make it possible for artsd to cascade audio input/output to another artsd
- ARTS_COOKIE, OSS_DEVICE

## C API / artsdsp

- implement an arts_stream_flush for writing half-written data packets
  (useful for implementing SNDCTL_DSP_POST in artsdsp)
- move to CSL (CSL a new common sound layer, especially intended to be
  compatible between Gnome and KDE)
- pkgconfig file
- it might be useful to allow clients on big endian systems to pass their
  16bit data with their native byte order - for compatibility with older API
  versions, its required to make this an extra parameter 
  as an efficiency bonus, one could also make the wire representation then
  16bit big endian, which requires support from the sound server though; its
  not required to implement the feature, though (which is probably useful
  for application writers on 16bit big endian machines)

## GUI Support

- port visual objects (beginnings are in kdemultimedia/arts/gui)
- hbox, vbox
- gui generation
- hints via mcopidl

## aRts Modules / Signal processing

- midi recording for Brahms
- StereoEffectStack should support reordering (and probably listing) effects
  (maybe backport noatuns version)
- hard disc recording
- allow progressive loading for wave files
- write blockwise caching (not requiring whole samples to be held in memory)
- akai support
- better interpolation / resampling
- the Resampler class should do big endian and float as inputs
- LADSPA support
- provide a GUI for stereo_pitch_shift

## kcmarts

- add restart option to the control panel, so that you can restart artsd easier
  if it crashed (it never crashes, does it ;) - close #38417 when done

## artsbuilder (and runtime)

- allow to give additional parameters (like names for sample files to play)
  through .arts-map files
- more examples (instruments, songs and such)
- gui editing (or should is it better to write a new editor for that)
- live editing of running structures
- component bar where you can choose components without going through all
  these submenus
- property editor (like in delphi)
- support pressing "return" in the various dialogs and close them on doing
  that (rather than always having to click "ok" with the mouse)
- i18n fixes

## artscontrol

- be able to remove midi ports                                          *KDE2.2*
- add a mixer
- persistent state (Arts::Environment), so that the environment
  can be restored on next login (or per song or something like that)
- edit .arts-map files visually

## Optimization (this section contains various optimization ideas)

- use no floats for adressing the fractional part in resampling but integers
  (that will be MUCH faster)
- use short int for i16le resampling, instead of using a long and adding
  sign manually (faster at least on athlon)
- tune the MCOP transfer protocol
  * rewrite Buffer not to use vector<char> to store data, but malloc'd blocks
  * try to write "zero allocation" invocations, that means, try not to allocate
    memory on performing an invocation. For instance Buffers could be kept in
	pools, and be reused for further invocations, without the need to realloc
	another memory block
  * try to minimize the amount of copies of data, possibly even using something
    like sharedmem to share data between the sending and receiving buffer
  * hardcode frequently used calls in the Arts::Object interface

## Documentation / Web

- improve kdoc comments everywhere
- write incomplete sections in The aRts Handbook; improve formatting

## Misc

- put streamwise blocking into MCOP, see artscat.cc to read really ugly
  source which lives without that feature
- implement plugins that transfer non-standard datatypes such as midi events,
  video frames, fft packets, oscilloscope views, ... (which was impossible
  with aRts on CORBA)
- make aRts run inside Brahms, KWave or your-favorite-other-app, to do
  signal processing where it is needed (similar to AudioLogic Environment,
  for instance)
- convince other people to use aRts, so that the usefulness of universal
  plugins written for the API increases
- when being crazy, implement gatewaying from MCOP to DCOP, CORBA, XMLRPC
  or whatever else might be useful

## Interoperability (GNOME/C)

- write a gartscontrol (in C) as native Gnome/Gtk app
- further work on CSL
- C language binding, based on glib
- mcopidl code generation for C

## FlowSystem changes:

It would be nice if the flowsystem became more "detached" from the normal
operation, making it ideally runnable in one or more thread dedicated for
audio processing.

Flowsystem transactions:

   these group operation like: starting, stopping, connecting, disconnecting,
   ... to transactions which will later (asynchronously) executed by the
   flowsystem

Example: problematic assertion

   assert(done[i] <= samples);    /* synthschedule.cc:998 */

   the problem with the assertion here is this - suppose some object reacts
   in a way on some signal that will lead to the creation of new objects,
   then those will get into the flowsystem, and we can't ultimately say
   anything about how far these have been calculated so far

   extremely problematic in this context are so-called call-ins, that is
   you do calculateBlock, and during this, the dispatcher mainloop gets
   called for some reason (I hope that this does not happen currently) -
   if that would hypothetically happen, then there the whole flowsystem
   could get restructured (because i.e. ordinary midi events could be
   processed)

## libartskde

 * ensure that there is a pair of classes, like KAudioPlayStream and
   KAudioRecordStream (or whatever they should be called) that can do
   approximately what the C API can do

 * don't export implementation details in the API - for instance
   KAudio(Play|Record)Stream should probably only inherit from QObject, and
   only "use" some aRts objects to do the actual work - that way, they can
   be changed/modified more easily afterwards

 * use Qt signals/slots as callbacks (at least as one possibility) for
   "please produce new audio data" / "here is new audio data" - that way,
   polling isn't necessary any longer