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

List:       kde-multimedia
Subject:    Re: Multimedia SIG results
From:       Antonio Larrosa <antlarr () arrakis ! es>
Date:       1999-10-22 21:55:52
[Download RAW message or body]

Stefan Westerfeld wrote:
> 
> - to give those that were in the SIG a remainder what we talked about

:-)

> =============================================================================
> 1. Goals
> =============================================================================
> 
> - signal to the outside world
> 
>   => what the hell are we going to do?
> 
> - get rid of CORBA in the realtime sector
> 
> - sort out different media types; provide one concept
> 
> - share the resources of the machine between many clients
> 
> - make it easy for people who are developing KDE2 applications to do "real"
>   multimedia development
> 
> - network transparency at least at the level of esd (?)
> 
> why (network transparency at esd level)
> - PR
> - people asked for it
> - computer pools
> - X11 philosophy
> 
> why not (network transparency at esd level)
> - introduces parallel approaches (CORBA vs. TCP streams)
> - security issues
> - PR (hard to sell that task A,B,C is network transparent,
>   while task C,D,E isn't)
> 

This is an exact copy from the paper we wrote, isn't it ? :-)
That's nice as there are always things that I forget.

Btw, I would like to note something. 
IMHO, we are diverging from the rest of KDE too much.
It seems that finally aRts will be the _only_ app in
KDE 2.0 that will use mico.
If we have a look at the size of that library,
we will find that _every_ user that wants to have sound
will have to load a 6 Mb lib just for aRts even if
all the apps they use only want to use a beep();

Adding that to the size of aRts itself and whatever more,
how many non-shared Kb. will take just the audio server ?
I suppose at least 8 Mb (6Mb from mico, 1 Mb for static
KApplication, etc. and 1 Mb for internal usage). That's
tooo much. I haven't done any test for this, so I may
be wrong (and I hope).

Would it be possible to do as the rest of KDE ?
I mean, moving from mico to dcop/kidl and all that ?
Even if these new libs takes also 6Mb of memory, at least
that will be shared among every app.

Please Steffen, think of it very seriously. The rest of
KDE is dropping mico because it's bloated and takes too much
room. If we continue using it, we will break their idea,
as we will keep it on memory.

> =============================================================================
> 2. Existing services/apis
> =============================================================================
> 
> =============================================================================
> 2.1. MidiClasses in KMid
> =============================================================================
> 
> These provide a
> 
> [ MidiManager ] -> [ External Midi ]   \
>                    [ Gus ]              | -> [ OSS/Alsa ]
>                    [ AWE ]              |
>                    [ FM ]              /
> 
> kind of concept. Parallel playing and displaying things in the Gui is
> handled by playing two timestamped series of midi events, one on the Gui
> and one against OSS/Alsa. While it works for pieces of music with a normal
> length, theoretically the Gui and the Output will diverge after some time.
> 

Of course, the gui is KMid, the "Output" (or as I prefer to call it, the
engine) is already separated. It's in a lib that only KMid uses, but I'll
move it to a more general lib that every app can use.

> 
> interface MidiChannel {
>     oneway void noteOn(in octet channel, in octet note, in octet volume);
>     oneway void noteOff(in octet channel, in octet note);
> };
> 
> As you see, this is by no means complete, nor fast, nor a very extendable
> concept. Just a quick hack. Should be changed.
> 

Will this be released on KDE 2.0 ? Or it will be disabled for the release
and improved after it ?

 
> =============================================================================
> 3.2 Midi
> =============================================================================
> 
> => MIDI Applications
> 
> - games
> - sequencing (play & record)
> - standalone
> - generic player (KMedia)
> 
> Plans for KDE2:
> 
> - KMid, KMidi as usual
> - Client API (I think this was a remark about Antonios kmidi classes)
> 

Yes, there will be a lib (on kdelibs ? ) that any app can use to have
(exclusive for KDE 2.0, shared later) access to midi synths. 
There will be a simple play(QString *file) function that just plays a
midi file. And also the internal classes will be available to be used
on Brahms, or Y for example.


> =============================================================================
> 5. roadmap
> =============================================================================
>

> - KMid/i, classes, libs

Ok,  this is my part of it for now (btw, it's just KMid :-) )

Greetings,

--
Antonio Larrosa Jimenez
antlarr@arrakis.es        larrosa@kde.org
http://www.arrakis.es/~rlarrosa
Klein bottles for rent -- inquire within.

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