Stefan Westerfeld escribi=F3: > = > Still, there remains a lot to be done. This document tries to provide a= > planning and discussion base for coordinating "the way to go". The focu= s > lies on what can be achieved for KDE2.1. > = Cool, I suppose you took into consideration the papers we wrote at Erlangen. > 1.2 Pluggable effects > = > aRts allows much more than vanilla playback. Filters can be used to aff= ect > how things should sound. Currently, this feature has been mostly unavai= lable > in the media player(s), mostly for two reasons: > = > 1. there were not too many effects > 2. binding a GUI to effects was not-implemented-yet > = > The fix for (1) seems obvious: write more effects. One starting point c= ould > be porting the FreeVerb code to the aRts architecture. > = > The fix for (2) is less obvious. The problem is that a way needs to be = found > how GUI objects (which run in the player process) can be connected to t= he > effects (which runs in the sound server process). The clean way to do t= his > is extending MCOP to provide a signals & slots technology. > = I'd like to propose doing an important change in aRts, and let it link to DCOP. Afaik, the only reason aRts is not linking to kdelibs and/or qt is so that the gnomes can use it in the future. But I don't see this happening, so not linking aRts to kdelibs/qt will only mean wasted efforts/time/etc. To provide signals/slots between different applications we should use DCOP, it's a standard they can also use if they want (by writing their own implementation), and would mean a reduction of code and simplification for ourselves. For signals/slots inside an own application, Qt is ok for KDE apps, glib/gtk/whatever is ok for GNOME apps, the only problem is artsd. But are the gnomes going to use the same artsd ? or are they writing their own ? If they're writing their own, I'm all for linking artsd to the kdelibs if that would mean a simplification of code and simplicity of our libraries. Please don't reinvent the wheel, there're reasons to use mcop for large amounts of transfers, but signals between apps is a work for dcop. > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > 2. New media types > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > = > 2.1 mikmod > = > There is work going on on making an aRts PlayObject for mikmod files, w= hich > would allow the KDE Media Player to play .xm, .s3m, .mod and others. As= always, > the component would be available to all other apps who know how to talk= to > aRts as well. > = Nice > 2.2 midi via timidity > = > A big idea would also be to make a timidity plugin for aRts. Timidity i= s a > package which renders midi notes to audio output using samples. Current= ly, > kmidi uses this to play its songs. Making an aRts PlayObject would agai= n > provide the user with a much more consistent experience. > = There's currently a timidity plugin for alsa, which allows to synthesize midi events by sending them to the alsa sequencer in the usual way (by libkmid). A kmid user told me that it worked, although I didn't try it yet. > 3.1 KDE multimedia webpage > = > KDE multimedia development needs to be more visible. There is no offici= al > coordination point where people can see whats going on right now. To so= lve > this, a KDE multimedia webpage (how does http://multimedia.kde.org soun= d?) > should be created. > = > Charles has volunteered to take care of this. > = cool, > 3.2 aRts documentation > = > First of all, the multimedia chapter of the KDE2 development book shoul= d > become available to the public RSN. While this is a significant piece o= f > good developer documentation, this is probably not enough. More work > needs to go into a consistent documentation on http://www.arts-project.= org > for both, developers and users. > = > 3.3 kdelibs/arts -> arts > = > Packaging aRts seperately is probably a good idea. aRts itself doesn't > depend on qt/kde, and this is intended. People outside the KDE world sh= ould > still be able to use aRts as sound server or for music tasks. > = should they? It would be very nice if they do, but I don't see this happening anytime soon. > If - for instance - Gnome would start using aRts, having it mixed in th= e > CVS and in packaging with KDE is probably a bad idea. > = Are you sure they're going to use artsd and not their own server ? > aRts in the CVS provides already midi realtime synthesis. You can do mi= disend, > and run instruments in artsbuilder. You can also combine it with Brahms= or > artstracker to compose songs. The problem with it is, that if you are n= ot > a rocket scientist, and study the code or collected READMEs for a while= , you > will probably not manage to do it. That has to change. > = > A good start would be providing an instrument manager, where you can > graphically assign which midi channel should get which instruments, wit= hout > bothering about the details. > = If alsa is doing this, I don't see any need to put midi synth very high on the TODO list, but better put real midi support there. > 4.2 Interoperability > = > There are at least three sequencer-like programs which actively want to= talk > to aRts: > = > * Brahms - which has been in the CVS for some time now - Jan is workin= g on a > new version right now - some aRts->midi support is in right= now > * Anthem - nothing done right now, Pete definitely wants to have audio= stuff > like hd recording, and probably aRts->midi support should b= e > added, too > * ArtsTracker - an experimental small tracker in kmusic > = > Especially the areas > = > * connecting to aRts > * finding (virtual) midi channels and synthesis instruments > * assigning instruments to channels > * sending timestamped events > = > need to be standarized more for midi. Other interesting fields include > = midi already standarizes a lot of things, again ... let's not reinvent the wheel ... > * harddisc recording > * effect processing > = > Most of this only needs a small amount of code in aRts and the applicat= ions, > the problem is finding a sophisticated standard. > = I miss a section of "optimizations on 2.1" :) Greetings, -- Antonio Larrosa Jimenez KDE core developer antlarr@arrakis.es larrosa@kde.org http://www.arrakis.es/~rlarrosa KDE - The development framework of the future, today. _______________________________________________ Kde-multimedia mailing list Kde-multimedia@master.kde.org http://master.kde.org/mailman/listinfo/kde-multimedia