'aRts TODO'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    aRts TODO
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-03-06 0:19:47
[Download RAW message or body]

   Hi!

I just reorganized the aRts TODO list, so this is what I intend to get done
next. Inside each section, it's approximately sorted by priority. We can
discuss this in detail on IRC later today.

Feel free to contact me if you want to work on some of the things mentioned
below (or not mentioned below ;).

   Cu... Stefan

## MCOP Core Infrastructure

- threading support (libmcop-mt)                                        *KDE2.2*
- offer sampleprecise timing
- resource management (i.e. locate resources like "samples" or "structures"
  in a similar uniform way KDE does with KStandardDirs)
- dynamic implementation of classes/attributes
- recursive scheduling again (with loops & cycles)
- ensure DynamicCast(<some null object>) == Object::null()
- implement StdFlowSystem::disconnectObject(...) (in synthschedule.cc)
- try to fix autoSuspend in conjunction with full duplex

## aRts SoundServer

- add kmessagebox style output of error messages (often, people         *KDE2.2*
  don't know why artsd is not running, does not start, doesn't like
  their soundcard,...)
- add -S option (to change the autosuspend timeout)                     *KDE2.2*
- export configuration interfaces from the soundserver (so that
  you can see and change the autosuspend timeout for instance)
- add -N option (to add extra network buffers)
- 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, NAS, ESD,
  AIX, Solaris)
- support channels != 2
- better defaults (i.e. realtime should be default)
- complain nicer when realtime rights not there
- expand capabilities of shell utils (making them eventually as powerful as
  artscontrol, or better ;)

## KMedia2

- seekable playobjects
- x11 embedding
- streaming of data from kioslaves into PlayObjects

## C API / artsdsp

- recording
- 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)

## GUI Support

- make a generic gui factory, make noatun and artscontrol use           *KDE2.2*
  it for effect guis
- make it easier to use them as qt widgets (i.e. no extra window)       *KDE2.2*
- 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

## artsbuilder (and runtime)

- should be able to put designed structures as modules in structures again
- 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)

- optimize bus rebuilding in bus.cc
- 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

## Documentation / Web

- improve kdoc comments everywhere
- add a section "what runs natively with artsd, faked via artsdsp, and
  not at all" to the aRts FAQ

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

## Interoperability (GNOME/C)

- glib mainloop integration                                             *KDE2.2*
- 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
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread] 