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

List:       kde-multimedia
Subject:    Re: LibKMid - A MIDI library
From:       Antonio Larrosa <antlarr () arrakis ! es>
Date:       2000-01-19 15:55:41
[Download RAW message or body]

Stefan Westerfeld wrote:
> 
>    Hi!
> 

Hello,

> On Mon, Jan 17, 2000 at 08:12:27PM +0100, Antonio Larrosa wrote:
> > Where should I commit it on CVS ? The intuitive place is kdelibs, but
> > not even aRts is there (it's in kdemultimedia), so perhaps libkmid should
> > be another main directory on kdemultimedia ?
> > Otoh, I hope to see every game from kdegames gets background music soon :)
> > but that would create a dependency from kdegames on kdemultimedia, is it
> > right ?
> >
> > The library doesn't link against Qt nor any of the kdelibs, so it may go
> > into kdesupport, but if I'm not wrong, kdesupport is for 3rd made software
> > and this has been done by us .
> >
> > I don't know where to commit it to . Ideas ?
> 
> If we intend to take it seriously with "KDE2 will offer significant
> improvements in the multimedia section", we have to put our stuff into
> kdelibs. Otherwise, either nobody will rely on it, or everything (even
> kdebase) will depend on kdemultimedia. So kdelibs is the right place, IMHO.
> 

I saw your mail on kde-core-devel (and the answers) just after I sent mine :)
So I suppose you're right and kdelibs is the right place.

> A short answer for aRts is, that it needs to be moved to kdelibs, too. Most
> of it anyway. I'm still thinking what and how. But at least mcop should be
> accessible. Your interface pretty much looks like the SimpleSoundServer
> interface, by the way. Perhaps we could make playing wavs and midis
> possible with the same API?
> 

Well, if you remember, we decided that libkmid was just a library, so it
doesn't have an "interface" like aRts does.

> interface SimpleSoundServer { // is something like
>   long play(string filename);
>   void stop(long id);
> };
> 
> SimpleSoundServer::_fromString("global:Arts_SimpleSoundServer") is expected
> to give you such a thing.
> 

The idea to integrate the midi/wav/mp3/whatever playing is nice, but that
would mean that the application shouldn't link to libkmid directly but just
call the aRts interface and let the aRts' server (which would be linked against
libkmid) play the file.

Although this is enough for KMidSimpleAPI (that is, games), it wouldn't work
with the full libkmid (that is, Brahms), as it has much more classes that
would need much more work (and time) to get integrated on aRts.

> If we could integrate MCOP in a similar way into KApplication like DCOP, it
> could startup itself on demand and terminate itself with the KApplication
> instance, so no need for the init and destroy calls.
> 

You don't want to propose this in kde-core-devel, do you ? ;-)
In any case, you could propose to add a KMMApplication (MM=Multimedia)
that would inherit from KApplication and do what you want.

> Basically, all it would need would be a void pointer in KApplication, which
> would point to an MCOP Dispatcher or to nothing.
> 

I can't see yet why aren't we using DCOP. Is MCOP significantly faster
than DCOP ? Some timings would be very nice to convince me :)

Also, once DCOP becomes a standard (and it's going to be one), we can benefit
from it, for example, being able to play music files (wav/midi/whatever)
in a script as well as the rest of KDE possibilities.

> The only thing that comes to my mind that is currently unclear is termination.
> 
> What is supposed to happen if you do server->play("foo.mid"), and you wait
> an hour?
> 

Do you mean in the current libkmid ? or in the "aRts' linked with libkmid"
version ?

>   -> for games: loop it all that time
>   -> semantic right now: play it once
> 

Not exactly, KMidSimpleAPI::kMidPlay has a loop parameter which tells if it
should loop or not. I suppose we can do the same in aRts.

> What is supposed to happen if you do a server->play("foo.mid") and your
> process exits?
> 

It depends if the game tells aRts to stop the music or not.

>   -> for games: stop it at once
>   -> semantic right now: play it once
> 
> The looping issue could be fixed easily adding another boolean. The process

Ouch, I should read the mail before replying :)

> exit behaviour is a bit different. Basically, the SimpleSoundServer class
> will not even "see" when the process exits. It could be fixed similar to
> the kmedia2 API (e.g. returning an object instead of a long), but then
> you loose something like typing
> 
> $ artsplay foo.mid
> 
> and having that return at once (though it is a question how you would then
> get rid of that file if you wanted to, especially if you have looping
> enabled ;)).
> 

artsplay -stop ?

or simply a symlink to artsplay from artsstop and check argv[0] in main()

> Well, what do you think? It would be nice to have SimpleSoundServer playing
> mp3's, mid's, wav's, which all may make sense as game "music" (I remember
> having an Amiga pinball game, which just looped an 8 second sample as music,
> which was quite okay, too ;).
> 

Have you ever heard Phillip Glass or Wim Mertens ? 
They can play the same notes for an hour (and the truth is that I like
it :) )

Greetings,

--
Antonio Larrosa Jimenez
Student of Mathematics
antlarr@arrakis.es        larrosa@kde.org
http://www.arrakis.es/~rlarrosa
KDE - The development framework of the future, today.

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