Index:

1. KDE2.2
2. To have more fun
3. Other suggestions

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

1. KDE2.2

- support threading in libmcop
- export configuration interface from the soundserver (so that you can see
  and change the autosuspend timeout for instance)
- add options
  -N  (to add extra network buffers)
  -S  (to change the autosuspend timeout)
- add kmessagebox style output of error messages (often, people don't know
  why artsd is not running, does not start, doesn't like their soundcard,...)
- make a generic gui factory, make noatun and artscontrol use it for effect
  guis
- ensure DynamicCast(<some null object>) == Object::null()
- implement StdFlowSystem::disconnectObject(...) (in synthschedule.cc)
- support multiple artsd instances on one computer (like multiple displays),
  and think of a clever way to register them
- StereoEffectStack should support reordering (and probably listing) effects
- StereoEffectStack should remove effects that are not longer referenced
 => some work of this is right now in noatun
- put streamwise blocking into MCOP, see artscat.cc to read really ugly
  source which lives without that feature
- port visual objects
 => beginnings are in kdemultimedia/arts/gui
- more work on flow graph descriptions (Structure, etc.) -- external interfaces
- port every object
- recursive scheduling again (with loops & cycles)
- reading/writing IEEE Floats needs proper documentation, testing on
  different architectures and probably different code for some machines
- allow progressive loading for wave files
- write blockwise caching (not requiring whole samples to be held in memory)
- recording, try to fix autoSuspend in conjunction with full duplex

2. To have more fun

- tune the transfer protocol (although MCOP theoretically could do 30000+
  synchronous invocations per second, it can only do 8000+)

  possible tuning operations are
    * 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

- 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-favourite-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

3. Other suggestions:

  => Documentation & Web

- make kdoc classtree available online
- add a section "what runs natively with artsd, faked via artsdsp, and
  not at all" to the aRts FAQ

  => aRts C API

- implement an arts_stream_flush for writing half-written data packets
  (useful for implementing SNDCTL_DSP_POST in artsdsp)

  => audio output

- maybe use some code from the XMMS-Solaris plugin for the aRtsd sound output.
  http://www.scms.rgu.ac.uk/staff/jr/computing/unix/xmms/ (is being worked on)
- maybe support mono? mmap? ... support other architectures (SDL, NAS, ESD, AIX)
