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

List:       kde-multimedia
Subject:    Re: KDE2.1 multimedia planning
From:       Antonio Larrosa <antlarr () arrakis ! es>
Date:       2000-10-29 0:16:15
[Download RAW message or body]

Stefan Westerfeld escribió:
> 
> 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 focus
> 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 affect
> how things should sound. Currently, this feature has been mostly unavailable
> 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 could
> 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 the
> effects (which runs in the sound server process). The clean way to do this
> 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.

> 
> ===============================================================================
> 2. New media types
> ===============================================================================
> 
> 2.1 mikmod
> 
> There is work going on on making an aRts PlayObject for mikmod files, which
> 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 is a
> package which renders midi notes to audio output using samples. Currently,
> kmidi uses this to play its songs. Making an aRts PlayObject would again
> 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 official
> coordination point where people can see whats going on right now. To solve
> this, a KDE multimedia webpage (how does http://multimedia.kde.org sound?)
> 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 should
> become available to the public RSN. While this is a significant piece of
> 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 should
> 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 the
> 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 midisend,
> 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 not
> 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, without
> 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 working 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 be
>                         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 applications,
> 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

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