diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 215 |
1 files changed, 215 insertions, 0 deletions
@@ -0,0 +1,215 @@ +- 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 TDEStandardDirs) +- 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 tdemultimedia/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.cpp 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.cpp: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 |