## 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)
- try to fix autoSuspend in conjunction with full duplex
- 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
- implement a preferences system for the trader, to be able to choose one
implementation over another if they both implement the same interface
- 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 { }; }; };
## 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, ESD,
alternative OSS driver using threads)
- 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
## KMedia2
- x11 embedding
## 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)
- pkgconfig file
## 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
## 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-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)
- 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)