**** BEGIN LOGGING AT Tue Mar 6 17:16:54 2001 17:16:54 ==> mETz has joined #kde-multimedia 17:17:02 --- mETz removes channel operator status from mETz 17:44:05 ==> Wild|AWAY has joined #kde-multimedia 17:44:27 Wild|AWAY: erster :) 17:49:35 back dir ein eis drauf, dummer bastard 17:49:36 :p 17:52:37 * mETz holt eis 18:17:38 === You are now known as mETz|eat 18:17:40 <== Wild|AWAY has quit [Read error to Wild|AWAY[p3E9C2BD3.dip.t-dialin.net]: Connection reset by peer] 18:18:56 ==> Wild|AWAY has joined #kde-multimedia 18:27:48 === You are now known as mETz 19:00:05 ==> jono__ has joined #kde-multimedia 19:02:02 ==> Duracell80|uni has joined #kde-multimedia 19:02:08 lo 19:02:10 hello all 19:02:16 jono__: lo 19:03:36 is this where the meeting is? 19:04:17 jono__: yep 19:04:32 2 hours to wait if I can count :) 19:04:51 Duracell80|uni: mETz: cool 19:05:13 21:00 GMT+1 19:06:07 :-) 19:07:29 === You are now known as mETz|away 19:09:47 ==> tranter has joined #kde-multimedia 19:17:02 === You are now known as mETz|kde2 19:37:45 * Duracell80|uni is still in a Multimedia sound lecture at uni 20:04:17 === You are now known as mETz 20:28:30 === Wild|AWAY is now known as WildFox 20:36:03 <== Duracell80|uni has quit [pohl.openprojects.net asimov.openprojects.net] 20:36:08 <== WildFox has quit [pohl.openprojects.net asimov.openprojects.net] 20:36:08 <== jono__ has quit [pohl.openprojects.net asimov.openprojects.net] 20:36:22 ==> WildFox has joined #kde-multimedia 20:36:22 ==> jono__ has joined #kde-multimedia 20:36:22 ==> Duracell80|uni has joined #kde-multimedia 20:36:22 ==> antlarr has joined #kde-multimedia 20:40:40 ==> MF has joined #kde-multimedia 20:40:48 hi 20:41:30 hi 20:44:06 Who is who? 20:44:07 :) 20:44:53 I am sound-developer 20:45:19 * mETz is sound ... hmmmm ... consumer :)) 20:45:59 just do a whois - my name is real ;-) 20:46:03 === Notify: KernelPanic is offline (pohl.openprojects.net). 20:46:46 <== antlarr has quit [Ping timeout for antlarr[62.37.130.142]] 20:46:48 :) 20:47:00 aRts dev? 20:47:20 no, i do not do coding 20:47:34 just making sounds and noises for kde2 20:47:39 oh 20:47:39 cool 20:48:12 ==> stw has joined #kde-multimedia 20:48:18 === Notify: KernelPanic is online (pohl.openprojects.net). 20:48:19 MF: ahh, some more sounds for arriving mail and such? 20:48:30 yes 20:48:36 * mETz also would like to choose from more login/logout sounds 20:48:42 Hi... ;) 20:48:45 the once we now have are from kde1 afaik 20:48:46 some people asked me to do some 20:48:50 MF: got a job for you ;))) 20:48:51 MF: only if you are interested, of course 20:48:55 stw: :) 20:49:00 stw: heh, just waited for you to join ;) 20:49:11 MF: have you experience with some "battle"-like sounds? 20:49:13 MF: @metz: you can find a startup sound written by myself on my webspace (url will follow) 20:49:29 * mETz "hearing" forward to that sounds 20:49:39 http://home.germany.net/100-330491/res/ 20:49:40 stw: metz: actually we still got ten minutes... 20:49:44 stw: I know 20:49:45 take a look at this 20:49:57 there are some click-sounds and a kde-startup sounds 20:50:09 wildfox: yes, i am of course interested 20:50:29 MF: wow cool 20:50:46 MF: check out "kdenonbeta/kbattleship" and hear those ugly sounds 20:50:54 MF: if you don't like them...tell me :) 20:51:02 MF: then i'd invite you doing new ones :) 20:51:17 wildfox: where exactly? 20:51:34 kde.org? 20:52:01 grr, kabboodle is mean 20:52:05 i could make sounds high quality: 44.1 khz, 16 bit 20:52:06 it does not play sounds 20:52:22 KDE Cvs 20:53:09 <== WildFox has quit [Read error to WildFox[pC19F9850.dip.t-dialin.net]: EOF from client] 20:53:15 ==> WildFox has joined #kde-multimedia 20:53:18 ==> schimmi has joined #kde-multimedia 20:53:43 hi 20:53:52 hi 20:54:03 re 20:54:12 === Duracell80|uni is now known as Duracell80 20:54:20 wildfox: i will check it as soon i know more about using cvs ;-) 20:54:40 MF: there is a howto on www.kde.org 20:54:47 thank you 20:55:50 i'll be back in a few minutes 20:56:06 mf: four minutes left ;) 20:56:13 yes :) 20:56:16 <== MF has quit [] 20:57:33 ==> antlarr has joined #kde-multimedia 20:57:36 hi 20:57:42 antlarr: hi 20:59:11 ==> Neil has joined #kde-multimedia 20:59:32 <== WildFox has quit [Read error to WildFox[pC19F9850.dip.t-dialin.net]: EOF from client] 21:00:41 hi 21:00:54 ==> WildFox has joined #kde-multimedia 21:01:04 === Notify: WildFox is online (pohl.openprojects.net). 21:01:04 * mETz watches his watches 21:01:08 and clocks 21:01:22 and they all show something around 9pm ;) 21:01:50 re 21:01:54 SHit OPN network 21:01:56 hi WildFox 21:01:56 *grml* 21:01:58 no 21:02:01 shit isp 21:02:01 ok, I think we can start ;) 21:02:02 :) 21:02:10 Njaard won't be long 21:02:15 he gets out of school at 12:00 today 21:02:23 hi Pressi 21:02:23 so I imagine he's hurrying 21:02:24 I have been doing a full list of realnames in the meantime 21:02:26 stw: yeah...i'm here ;) 21:02:36 http://space.twc.de/~stefan/kde22.html (so thats if you want to have things deanonymized) 21:02:43 :) 21:02:45 yeah 21:03:03 * jono__ listens 21:03:04 :-) 21:03:24 stw: recheck your url please. doesn't work here :/ 21:03:28 stw: was "Z" immermann too long to type ? ;) 21:03:45 schimmi: it's fine 21:03:59 it's fine?? 21:04:01 stw: whoops 21:04:07 neil: ok, we might wait another two minutes for njaard 21:04:08 stw: i forgot to set my real nickname :) 21:04:08 * schimmi wonders what's up with his inet connection 21:04:15 schimmi: telekom ? 21:04:23 url works here 21:04:27 here too 21:04:40 WildFox: yep, but I only forgot the l at the end of the url :) 21:04:47 LOL :) 21:05:01 schimmi: believe me...you didn't 21:05:04 schimmi: it's tee-offline's fault ;) 21:05:10 they absorded it ;) 21:05:14 WildFox: of course :) 21:05:35 * schimmi wonders whether it has some meaning that 30% of the people here are called stefan 21:05:45 * WildFox finished his long i18n("Referat") about i18n("Kernfusion") 21:05:48 svhi: LOL 21:05:51 schimmi: LOL 21:06:11 ok, I just added the URL for the aRts todo list to the page, so if you haven't seen that yet, you can do now ;) 21:06:27 WildFox: still having your flatrate? :) 21:06:42 WildFox: mETz: yep until next year, feb 21:06:42 :) 21:07:00 WildFox: pweeww, I already lost it (well, i T-Onlinewould care about me) 21:07:14 stw: is this meeting also intended to assign aRts tasks? 21:07:21 WildFox: I haven't payed anything since dec 28th and I'm still online 21:07:33 is arts going to eventually support all types of media such as sound, video, animation, dvd video etc? 21:07:44 ==> ManuelF has joined #kde-multimedia 21:07:45 jono: at leat thats the plan 21:07:48 re 21:08:07 wildfox: yes, it should be about coordinating who does what and why 21:08:12 cool :-) 21:08:13 ok 21:08:23 wildfox: it's me, MF 21:08:34 ok :) 21:10:00 so, you need sounds, please tell me for what and in what situations they are needed? 21:10:01 Ok, anyway, no Njaard yet, so I guess we'd better start, he'll somewhen find his way here 21:10:08 uh oh 21:10:17 I like one TODO item on there, even if Njaard won't :-) 21:10:31 kaboodle 21:10:46 Neil: njard also does not like indenting with spaces ;) 21:10:49 I've been telling him to share noatun and artscontrol things for ages 21:10:51 Ok, my strategy for now would be that we talk our way once throught the aRts TODO list 21:11:08 stw: the TODO is the mail you sent to the lists ? or did you add things to the web page ? 21:11:18 Then we can add custom things like kaboodle, kmid, fft. 21:11:27 ==> tobi has joined #kde-multimedia 21:11:28 antlarr: it's the same version 21:11:30 hi all 21:11:39 stw: ok 21:11:45 That would be most I want to talk about 21:12:00 And yes, if anybody has more to add, we can do that then, ok? 21:12:06 stw: please don't get into detail too much. we should really focus on the major direction only IMO. details can be discussed later on 21:12:17 * stw would like to welcome everybody, by the way 21:12:35 schimmi: ok, no details 21:12:39 ;-) 21:12:45 :) 21:12:48 stw: hi ;) 21:13:02 So. First point. 21:13:08 Topic is everthing in ## MCOP Core Infrastructure 21:13:39 Perhaps I'd explain first: the threading thing: 21:13:43 - ensure DynamicCast() == Object::null() 21:13:45 important 21:13:46 :) 21:13:53 mpeglib is threaded 21:14:00 decoders are threaded 21:14:21 So basically, the first point is about making aRts threadsafe enough to develop threaded playobjects and such 21:14:31 It's mostly done anyway, so it will be in KDE2.2 (libmcop-mt) 21:14:48 It uses a big lock, so at least it can ensure that you can write threaded playobjects 21:15:18 wildfox: the dynamiccast and stdflowsystem thing are more or less bug cleanups, but I am not sure if they get into KDE2.2 21:16:04 ==> gis has joined #kde-multimedia 21:16:06 Ok, the other stuff should be self-explaining or not too relevant ;) 21:16:23 So.. any question to the first section? Anybody wants to implement anything of that? 21:16:29 re gis 21:16:38 stw: of the MCOP stuff? 21:16:53 ==> Njaard has joined #kde-multimedia 21:16:56 stw: is there a README or TODO document in the CVS? 21:16:56 sorry buddies :) 21:17:06 njard: you didn't miss toooo much yet 21:17:09 njaard: hi ;) 21:17:13 wildfox: yes 21:17:33 stw: DCOP<->MCOP bridge would be nice :) 21:17:36 oh 21:17:39 that's ## Misc 21:17:43 i forgot 21:17:49 Njaard: you only missed an explanation of MCOP threading 21:17:58 ==> ach has joined #kde-multimedia 21:18:14 wildfox: if you volunteer for that, I have some code for you to start with, it's not too hard 21:18:23 wildfox: though it's not too important IMHO ;) 21:18:47 good 21:18:50 because I don't care about that ;) 21:18:55 :) 21:19:03 Ok, anyway, thats just core stuff and while important not so much of a general thing of the direction of the development 21:19:10 i'd like kio -> playobject 21:19:20 streaming 21:19:25 me too wild 21:19:32 wildfox: then wait a bit until we're there 21:19:36 ;-) 21:19:43 So, I'll simply go to ## aRts SoundServer 21:19:45 ok 21:19:45 :) 21:19:47 Njaard: we could to that together :)? 21:20:13 * stw points everybody who wasn't there at the beginning to http://space.twc.de/~stefan/kde22.html 21:20:21 we meaning you, yes :) 21:20:36 no :) 21:20:36 heh 21:20:37 together ;) 21:20:54 WildFox: Njaard does everything alone you know ;) 21:20:54 Ok, soundserver isn't too much spectacular things 21:21:06 hehe 21:21:09 stw: not found. 21:21:11 The general idea is to gain a bit user friendliness here 21:21:17 stw: sorry, forget it. 21:21:26 hehe 21:21:44 * mETz 'd like to see a messagebox when artsd died and not arts-apps crash 21:21:56 lol 21:22:04 when an app dies..how to display an error ? :) 21:22:09 ie when it segfaults 21:22:12 lotsa commits, none I care about 21:22:13 ;) 21:22:18 I was conservative about what to do for KDE2.2, so I just added a bit of stuff with a *KDE2.2* marker 21:22:30 stw: metz: the problem with the crashes is this: 21:22:47 stw: metz: when artsd dies, all operations returning OBJECTS will return null pointers 21:23:11 stw: metz: so for instance the operation soundserver.outstack().insertTop(someEffect,"name") 21:23:14 stw: so apps should have to constantly test for Null-Pointers :/ 21:23:30 stw: metz: which works fine with a running artsd will produce a crash without a running artsd 21:23:32 hence the importance of returning Object::null 21:24:06 stw: metz: what I'd suggest to fix this (if we want to fix it at all), is to trap null pointer dereferencing to a handler rather than an assertion 21:24:10 Though it still seems like apps really can't be expected to handle a dying artsd gracefully 21:24:28 Do KDE apps handle a dead dcopserver? 21:24:37 no 21:24:49 stw: metz: that way we could display "your app has dereferenced a null pointer, which means that artsd isn't there", and so could gracefully exit(1) after that instead of calling abort() 21:24:58 they provide a nice error message text box from dr konqi 21:25:07 heh 21:25:09 something about signals and segfaults 21:25:10 stw: metz: I don't want to clutter up *all* code with null pointer checks, really 21:25:11 Njaard: hmm 21:25:32 stw: besides that would not help to speedup things 21:25:35 Neil: no, but I didn't have a dcopserver crash for ages :) 21:25:41 stw: metz: I mean, dereferencing an aRts null pointer isn't the same as dereferencing a C null pointer 21:26:05 stw: metz: it wouldn't be slower than it is now (assert is an if anyway) 21:26:09 * stw looks around 21:26:23 anybody wants to implement that and add it to all aRts apps? 21:26:33 * Njaard gives a mirror to stw 21:26:43 * Njaard should stop doing stuff like that 21:26:43 stw: anyway, arts can crash between the check for a null object and the use of that object, so that's not a solution 21:26:55 antlarr: no it can't 21:27:26 antlarr: the problem isn't calling a function on an object that *used to be there*, and now *isn't any longer* due to a crash 21:27:37 stw: it can't ? 21:27:37 antlarr: that kind of stuff is catched in the .error() condition of any object 21:27:45 antlarr: so basically if you do 21:28:00 antlarr: SoundServer s = Reference("Arts_SoundServer") 21:28:12 antlarr: if(!s.isNull) { s.terminate() } 21:28:50 antlarr: then after the s.terminate() { remote call } s.error() will be true if artsd crashed somewhen after being assigned 21:29:05 antlarr: and s.isNull() will be true if artsd crashed before being assigned 21:29:10 antlarr: so you can check everything 21:29:31 So... anybody wants to implement that? Last call? ;) 21:29:48 * WildFox looking away 21:29:51 Thi sis going very slowly :-) 21:30:02 * tobi would like to help, but i'm not sure if i'm capable of it. 21:30:04 Ok, nobody. 21:30:06 I think more people would be willing to implement it if, er, they knew how 21:30:11 Njaard: exactly 21:30:18 Ok, another try: 21:30:19 same here 21:30:20 which brings us to the arts documentation conversation 21:30:28 overriding the operator-> is simple, but is it the solution? 21:30:41 Who wants to implement it if you can ask me any question by mail, and I promise to answer it? 21:30:42 Njaard: that probably belongs under Misc 21:31:01 tobi: you? 21:31:04 stw: you'll get things like "How to do?" :) 21:31:07 yes, yes :) 21:31:11 well, a preliminary "yes". 21:31:20 stw: implement what ? error dialogs ? 21:31:30 checks ? 21:31:34 no, the basic error handling/checks. 21:31:37 stw: you'll end up writing it with everyone else asking you how to :) 21:31:37 antlarr: the null pointer dereferencing -> sane condition thing 21:31:42 antlarr: actually it will be really simple 21:31:51 *phew* 21:31:58 njaard: I'll write it in the documentation then at least, so the next time it will be easier 21:32:10 * WildFox thinks about .... 21:32:10 ## KMedia2 21:32:15 Ok. 21:32:26 stw: and add to our agenda "playing without gap between tracks" 21:32:27 Wildfox: wait. ;) 21:32:30 I'd like to close down the other section first 21:32:32 stw:: :) 21:32:32 stw: Yes, I should probably take the explanation of playobjects you gave me and turn it into documentation 21:32:35 good idea 21:33:08 neil: good, *please* do that 21:33:15 njaard: is that a ##soundserver item? 21:33:22 maybe 21:33:27 it may even be an mpeglib item 21:33:47 njaard: ok, then lets discuss this now 21:33:58 njaard: so what kinds of gaps do you mean 21:34:16 play a file, when that ends, there's a gap ~.5 sec between the current and the next 21:34:59 njaard: could that be related to the fact that you are polling when the file has ended? 21:35:08 Njaard: that's probably best-fixed on the noatun side 21:35:12 stw: that helps :) 21:35:16 just start up the next song just before the last one ends 21:35:16 Neil: it's not noatun to blame 21:35:26 there's just no accurate way of knowing when a song has ended 21:35:33 njaard: *yes* there is 21:35:44 I mean, the length of the sond 21:35:48 [12:34:17] just start up the next song just before the last one ends 21:35:58 njaard: you can connect the status change notification of the playobject to some object in noatun 21:36:01 you can't play it "just before" the previous end 21:36:09 njaard: then you'll get a notification when it has ended 21:36:13 stw: QObject slots 'n signals? 21:36:16 qtmcop? :) 21:36:27 when did this happen? :) 21:36:28 OK, then I suppose we still need accurate notification of when the song ended immediately 21:36:39 I see 21:36:42 njaard: and to be sure that you exactly catch it, you might want to load the other file before the first ends 21:36:46 stw: right 21:37:00 loading the file is a good idea 21:37:00 that's the right idea I almost had :-) 21:37:06 neil: we *have* accurate notification, it looks like connect(playObject,"state",yourguard,"statewatch"); 21:37:20 yourguard inherits QObject ? 21:37:23 stw: ok good :-) 21:37:23 neil: if playobjects do not send out this notification, they need to be fixed 21:37:28 and slot void statewatch(..) ? 21:37:47 neiL: no, yourguard needs to be an MCOP object, too 21:37:54 anyone who wants sounds for applications should query me. thank you 21:37:55 guess it's Engine, then ;) 21:38:30 Njaard: so do you want to do it, or should I? 21:38:31 neil/njaard: one of you should raise his hand now and say: "I'll take care of that for KDE2.2" 21:38:45 njaard: or do you not want it to be fixed in KDE2.2 21:38:47 * Njaard helps Neil with his heavy arm 21:38:50 heh 21:38:54 :) 21:38:57 ok, I guess I'll do it 21:39:02 stw: just consider it a collective OK and moveon 21:39:03 :-) 21:39:08 stw: but how do I turn engine into a mcop object as well 21:39:20 next item is... 21:39:21 ? 21:39:34 Njaard: you missed when we said we didn't want to discuss too much detail 21:39:36 njaard: make an idl file, and inherit the _skel file 21:39:41 Neil: yes, yes I did 21:39:44 * stw is closing down ##soundserver now 21:39:55 --- more questions by mail --- 21:39:55 stw: like everything else? :) where is an example class? 21:40:05 bah! :) 21:40:16 stw: where do i need to start? 21:40:22 njaard: there are lots in kdelibs/arts/examples ;) 21:40:38 tobi: have a look where the assert fails, that should be a good place to start 21:40:39 arts/mcop/??? 21:40:40 er :) 21:40:41 heh 21:40:43 * stw is moving to ## KMedia2 21:40:52 so x11 embedding means embedding of video? 21:40:57 Before we move on: The two SoundServer items marked *KDE2* look pretty easy. I should have time to work on them. 21:41:01 yo 21:41:02 playobjects arn't seekable yet? :) 21:41:13 Neil: yes 21:41:15 maybe it means to make more objects seekable 21:41:22 I think that falls under the standard-playobject clause 21:41:30 which arn't? 21:41:35 tranter: ok 21:41:49 I have *NOT* added any KDE2.2 markers to that ##kmedia2 section 21:42:14 Thats since I have not enough time to care about them, so anything here is up to you - and Martin, probably 21:42:21 Anyway, let me explain first: 21:42:58 Currently, Arts::PlayObject has as interface for specifying what to play a bool loadMedia(string filename) thing 21:43:11 That is, PlayObjects *always* play local files, and nothing else 21:43:29 Thats suboptimal, because you can't for instance get an mp3 from a web server (via KIO) and play it 21:43:42 The items #1 and #3 are about fixing this 21:43:48 * Neil thinks that Njaard probably knows the most about how to get streaming working 21:43:57 #1 because it will be hard to make such a playobject seekable as well 21:44:11 does arts allow the developer or user to spread sounds around the audio field like surround sound, and does it support multiple speakers? 21:44:39 jono__: Have you taken a look at OpenAL? 21:44:47 jono: there is one item in ##soundserver (channels!=2) related to that 21:45:11 jono: currently artsd supports 2 channels at most, this is why you will not have surround sound for instance 21:45:21 jono: I can't really fix it because I have no multichannel card. 21:45:29 I like the idea of noatun giving the data to arts 21:45:37 please, let's keep an order on the subjects we talk about :) 21:45:44 noatun interfaces with the ioslaves, that is 21:46:03 antlarr: right 21:46:04 jono: please ask again once we are through with everything ;) 21:46:11 So back to ##kmedia2 21:46:11 errm 21:46:19 stw: there's a standard for that, RTP and RTSP 21:46:24 there is no sounddriver supporting 4 channels afaik 21:46:32 stw: metz: alsa does 21:46:33 ahh ok 21:46:38 at least my sb live is no real 4 channel card 21:46:39 As far as x11 embedding, I've already been working on something similar, so I suppose I could do so with arts, and see what I can do with mpeglib 21:46:40 stw: sorry for butting in 21:46:44 :-) 21:46:49 stw: metz: please you too wait with that ;) 21:46:56 stw: ok 21:47:10 neil: and you wait, too ;) 21:47:23 * stw tries to concentrate again 21:47:28 e too 21:47:28 tries? ;) 21:47:36 anyway: so we're on #1 and #3 again - seeking, streaming 21:47:37 the question is if we should support that standard" or do it by using the kioslaves somehow 21:47:59 stw: streaming CAN be done w/o #1, right? 21:47:59 stw: the basic stuff 21:48:00 we need to be able to stream from, e.g., kio_smb 21:48:06 antlarr: RTP is a protocol for media over internet, right? 21:48:10 just ie. noatun does 21:48:12 stw: i think i know what to do now. 21:48:29 soundServer->playData(QByteArray) 21:48:34 stw: yes, and RTSP is the "controlling" protocol, 21:48:35 can we quit using e.g.: e.g., and i.e.? :) 21:48:40 and the soundserver plasy 21:48:50 antlarr: I think we should use the MCOP standard for doing so, not RTP 21:48:50 it'd be nice if #3 did #1, though, because that's what users will expect 21:48:51 and the soundserver plays 21:49:12 wildfox: there is a superior (I hope superior) method for streams 21:49:15 Arts::DataSource 21:49:15 i'd say let's pick up my basic idea 21:49:18 that noatun creates 21:49:31 then a virtual "seekTo(unsigned long byteoffset)" 21:49:32 wildfox: it looks like connect(stream, "outdata", playobject, "indata") 21:49:34 stw: you can ask the server (via RTSP) to PLAY, PAUSE, etc, and the data will be sent to you using RTP 21:49:36 we just need queueing 21:49:41 Njaard: it'd be nice if all apps didn't have to recreate the wheel, though 21:49:47 stw: rfc2068 and rfc2326 21:49:55 Neil: it'd be nice if X11 didn't suck too ;) 21:50:01 stw: nice 21:50:02 stw: does it has queueing? 21:50:09 Njaard: yes, but we can do something about arts 21:50:09 wildfox: yes 21:50:16 ;) 21:50:27 stw: perfect 21:50:36 stw: so what is missing ??? 21:50:37 * stw points everybody at http://www.arts-project.org/doc/mcop-doc/async-streams.html 21:50:53 [ please read that before suggesting alternative stream models ] 21:51:18 mmmhmmmm :) 21:51:18 async streams are *also* used by artscat and artsdsp (and the C API) so they are quite tested 21:51:40 besides, they use intelligent queueing and are quite good at optimized transfer (via MCOP). 21:51:42 but can it make coffee? :) 21:51:55 so that's available today? hmmm 21:52:00 lol 21:52:01 stw: so 21:52:02 * Neil sees the Kaboodle TODO Growing 21:52:07 stw: what is missing ?? 21:52:08 WildFox: so now to the "what it *can*t* do" part 21:52:22 The problem is that streams like in aRts do not do seeking at all 21:52:24 libartskde 21:52:28 This is why #1 is there 21:52:33 like we have libartsglib 21:52:45 * stw points njaard to libqtmcop 21:52:48 stw: ermm 21:52:52 stw: that's fine with me 21:52:56 stw: for the moment 21:53:00 stw: yes, but that doesn't link to kio 21:53:02 stw: but what about #3 ? 21:53:09 we should just do the KDE magic in there 21:53:34 Njaard: we *CAN* use kioslaves (actually that is what I intend to do) 21:53:42 Njaard: so the process of playing a file would look like 21:53:54 we want it to be as app transparent as possible 21:53:57 Njaard: [ kioclass ] ------ MCOP stream ------> [ playobject ] 21:53:58 inclding stuff like KURL 21:54:14 njaard: where kioclass would run in some K-Process (i.e. noatun) 21:54:25 njaard: and [ playobject ] would run in artsd 21:54:33 njaard: that way, everybody should be happy 21:54:34 that sounds fnie 21:54:35 fine 21:54:39 fnie too 21:55:18 but 21:55:24 ok gotta go... 21:55:24 we have to implement it first? 21:55:28 thanks guys 21:55:30 cu jono 21:55:30 nothing's done on it yet? 21:55:32 jono__: bye 21:55:37 seeya :-) 21:55:40 cu 21:55:42 <== jono__ has quit [leaving] 21:55:43 jono: cu, thee will be a log file 21:55:53 :)) 21:56:09 <== Duracell80 has quit [leaving] 21:56:15 I think this is on-topic ... would there be any problems if one added a createPlayObject alternative that uses mime-types? 21:56:23 neil: no 21:56:29 or would that break compatibility/ 21:56:35 neil: actually createPlayObject is quite broken anyway 21:56:36 ok 21:56:39 we can export some of noatun into a libartskde 21:56:44 so kaboodle can use it to 21:56:45 o 21:56:49 neil: BC can be kept easily ;) 21:56:59 Njaard: you know what my motivation is rather well :-) 21:57:13 bah :) 21:57:41 Neil: I'm thinking of exporting all of libnoatun into a namespace, btw 21:57:48 OK, so I'll have to try to port Noatun's mime-type stuff into arts instead of into Kaboodle 21:57:52 much cleaner 21:58:02 Ok, as for the PROBLEM: lets just say: there is a problem with seeking, and you'll find it when you implement it 21:58:03 or actually that'd be good for a libartskde 21:58:09 to wrap the KMimeType stuff 21:58:19 It should be more or less trivial to solve though, so... 21:58:24 hey 21:58:27 guys wait pls 21:58:27 For #1 and #3: 21:58:33 i'd say let's give the word to stw 21:58:40 and everybody else shuts up :) 21:58:47 wildfox: good idea ;) 21:59:27 #1 and #3: 21:59:27 If anybody wants to see that with a nice *KDE2.2* tag, then you need to implement it 21:59:30 So anybody wants to care about it? 21:59:38 :) 22:00:14 I care, in the same way I care about cold fusion 22:00:14 What needs to be done for #3 22:00:16 I just can't do it :-) 22:00:46 wildfox: interface StreamablePlayObject { in async byte stream indata; } 22:01:01 wildfox: then make the PlayObject read from indata rather than a file 22:01:04 wildfox: thats it ;) 22:01:19 wildfox: you'll need to extend the createPlayObject function, too 22:01:26 I just can't do it :-) 22:01:28 wildfox: and implement at least one reference playobject 22:01:34 i'm true 22:01:38 i have no clue about interface 22:01:50 and async, too 22:01:52 that's my whole problem 22:02:08 WildFox: maybe you could do it after I write a PlayObject docs 22:02:09 wildfox: there is a section in the kde2.0 development book that explains enough about it 22:02:33 wildfox: and lots of source in kdelibs/arts, too 22:02:59 Neil: perhaps then 22:03:00 ;) 22:03:00 * stw would like to do a short survey 22:03:23 all: who feels qualified enough to implement a new Arts::StereoEffect which swaps the left and right channel? 22:03:49 same again :( 22:03:49 all: please raise your hand ;) 22:04:12 stw: it seems like you have to do aRts work until you are death :( 22:04:14 qualified, but running out of ree time :-) 22:04:18 qualified, but running out of free time :-) 22:04:50 neil: that was not the question here, suppose you had no other obligations 22:04:55 ah, ok 22:05:04 so assuming I had no other obligations I could do it 22:05:17 i must go. cu 22:05:18 that stuff *is* covered in the book :-) 22:06:00 bye ManuelF 22:06:23 looks like I'm stuck with it then 22:07:59 <== ManuelF has quit [] 22:08:00 * mETz found something to work on in the TODO, even it is not important but it's a todo :) 22:08:36 Neil: mETz: that mean you want the stereo reversal? 22:09:02 Neil: no, I'm not goddish in coding yet :) 22:09:28 <== stw has quit [king.openprojects.net lackey.openprojects.net] 22:09:52 * mETz is rather happy to have that noatun/xmms-applet almost prepared for cvs 22:10:03 this wouldn't take goddish coding 22:10:12 ==> stw has joined #kde-multimedia 22:10:15 The KDE development book should give you all the knowledge needed to do that 22:10:26 Neil: I never even had a look at doing music-stuff 22:10:29 There's no way I'd be qualified to do it otherwise :-) 22:10:47 <== stw has quit [Leaving] 22:11:19 * mETz wonders wether stefan is playing with /part 22:12:02 maybe he's trying to switch servers 22:13:41 of all people he's the one we don't want to go on without 22:14:11 :-( 22:14:17 ==> stw has joined #kde-multimedia 22:14:31 Sorry, strange ISP effect or something like that ;) 22:14:34 ok 22:14:47 nothing happened without you, don't worry :-) 22:15:24 so we're probably on the C API now 22:15:30 Good, I went somewhen after asking who was qualified for implementing MCOP objects - did that give a non-zero result ;) 22:15:35 * schimmi wonders whether it has some meaning that 30% of the people here are called stefan 22:15:42 argl 22:15:53 stw: I never say you say that... 22:16:08 last thing I say you say was "no other obligations..." 22:16:12 * schimmi tried to control his keyboard the whole arm 22:16:29 neil: oh well, anyway 22:16:31 schimmi: I'm not guilty, its my parents ;) 22:17:02 neil: I just wanted to know whether implementing an MCOP object (like using mcopidl -> deriving -> implementing) is common knowledge or no? 22:17:15 I don't think it is 22:17:34 I'd have to read some docs to do it 22:17:36 well, not for me either - i'm new to arts/mcop devel. 22:17:39 :-} 22:18:12 Just about nobody knows anything about arts it seems 22:18:22 that's why so many people whine endlessly about why "noatun is broken" 22:18:22 Hm. Because you'll need that for doing anything on aRts, you know 22:18:28 yeah 22:18:40 So other question. 22:18:52 I know I could do it, but it's not familiar to me yet 22:19:18 Njaard: you can do it too, right? 22:19:24 anyone else? 22:19:24 Ok, who wants to learn implementing an MCOP object? 22:19:40 * tobi ! 22:20:00 with the andamooka book, i should be able to, no? 22:20:10 tobi: yes, should be no problem. 22:20:25 fine. :-) 22:20:44 njaard: and you should, too, because if you want to make Noatun::Engine one, you'll need to know ;) 22:20:54 Noatun has all those effects 22:20:57 so I'd think Njaard knows how 22:21:12 * stw looks at njaard 22:21:29 * WildFox blames nj°rd 22:22:00 * mETz pokes Njaard's body which does not move anymore 22:22:07 anyway, good, it's really *NOT* magic to work on aRts, and I strongly recommend doing it ;) 22:22:15 * stw returns to the list now 22:22:19 it's not magic, it's just a lot to learn all at once 22:22:25 it's kind of complicated 22:22:28 yeah, right Neil 22:22:36 wildfox: you'll try to do them? 22:22:37 and all those c++ stuff, to learn 22:22:57 #1 and #3 22:23:02 I mean 22:23:21 hmm 22:23:26 #1 - i have no clue 22:23:34 #3 - i _could_ try to do 22:24:07 I thought Njaard and I were going to 22:24:15 via a sort of libartskde 22:24:21 neil: oh, right 22:24:23 porting the noatun stuff over 22:24:25 so moving on 22:24:26 :-) 22:24:32 * stw is still confused due to that network outage thing 22:24:36 yes 22:24:42 anybody doing #2? 22:24:47 yes, I was going to look 22:24:56 since I was already working on embedding graphic windows 22:25:05 ok 22:25:11 So any more questions to the section? 22:25:17 question: why do we use server-side playobjects? I know that's bold now, but i doubt that's an efficient design. 22:25:20 i can mail you, if i need help ? 22:25:30 wildfox: yes 22:25:36 good 22:25:41 tobi: depends 22:25:45 ok C API / artsdsp 22:25:56 tobi: server-side means you need not stream data around 22:26:06 * Neil would hope that artsc doesn't fundamentally change, having already ported a bunch of stuff to artsc 22:26:10 tobi: server-side also means best latency 22:26:12 right. that's all about the problem with seeking. 22:26:24 stw: i agree. 22:26:41 tobi: MCOP is transparent, so you *can* instantiate the playobjects client-side if you want to 22:26:55 tobi: they are just libraries (implementations of objects anyway) 22:27:15 i see, but isn't that a bit too .... 22:27:23 ... unstable/insecure? 22:27:45 it's like creating an ORB 22:27:56 tobi: aRts is mostly an ORB ;) 22:28:04 arts once *used* CORBA 22:28:20 but this isn't the time to argue arts design 22:28:20 :-) 22:28:27 you're right. 22:28:28 * stw agrees with neil 22:28:34 let's move on. 22:28:36 tobi: you can discuss that with me some other time 22:28:42 just wanted an opinion. 22:28:50 stw: so were you planning on scrapping the existing artsc? I can't tell what you mean in that TODO 22:28:52 s/ed an/ed to hear an/ 22:29:08 * stw ## C API is next 22:29:18 Oh yes 22:29:26 Brief introduction to CSL and such: 22:29:54 When I talked to various Gnome people about aRts, it seemed to be that they wanted a pure C implementation for the CLIENT 22:30:12 I sat down with Tim Janik (glib developer) 22:30:42 So we started with doing a full-blown MCOP implementation in C, and decided that that was a bad approach 22:30:54 because in the end it would mean that you had two MCOP implementations to maintain 22:31:26 Nevertheless for the client a pure light weight C thing is probably better than always using the full C++ implementation just for the client 22:31:40 ok, i'll take the time to read the arts chapter now. CU soon! 22:31:47 <== tobi has left #kde-multimedia 22:31:52 good luck tobi 22:32:01 So we sat down and implemented CSL, which is just a minimal C MCOP impl, which should eventually be able to replace aRts C 22:32:21 That would be the time to implement recording, too 22:32:38 As CSL is not yet released, and just an unofficial thing to play with, there isn't much more to say 22:32:46 it's just that when SDL, and some other things, already have some artsc, I'd have tor arts to be ditched so soon 22:33:03 I'd hate for artsc to be ditched so soon, rather 22:33:17 Neil: It will *not* be ditched 22:33:23 OK good 22:33:23 Neil: It will be kept for compatibility 22:33:43 Neil: just the implementation will probably sooner or later end up being written in C, and being called CSL 22:33:45 Neil: thats all 22:34:05 ok 22:34:06 That's all I'd ask :-) 22:34:06 So - any more question to the C API section (/me tries to hurry up) ;) 22:34:31 Not. good 22:34:36 ok 22:34:36 ## GUI Support is next 22:34:52 The idea of that one is that effects (like freeverb) will need a GUI 22:34:54 and it's a shame that Njaard seems to be idel for this part 22:34:57 idle 22:35:16 The GUI should be sharable between artscontrol and noatun (and other possible aRts aware apps) 22:35:17 Neil Njaard 22:35:20 since effects are one thing I've left solely up to Njaard 22:35:21 * mETz thinks Njaard isn't idle but in fact Njaard|away 22:35:26 in noatun 22:35:46 So I thought we might be able to do that until KDE2.2 22:36:06 In fact, I'll try to produce a simple interface where you just can say "give me GUI for effect foobar", and you'll get one 22:36:07 wasn't arts meant to not rely on qt 22:36:27 Neil: mETz: that's the point.. gtk can have its own implementation of GUI items 22:36:30 stw: metz: yes, thats why Arts::Widget, Arts::Panel, Arts::Poti and so on are interfaces 22:36:37 just like one can have different implementations of players 22:36:44 ahh 22:36:48 stw: metz: they have a "Requires=kde_gui" line in the implementation 22:36:54 (.mcopclass file) 22:37:10 Anyway, it would be cool if somebody would write the equivalents for gtk 22:37:19 If anybody is interested? 22:37:28 But I doubt this is the right place to look for gtk programmers ;) 22:37:33 exactly 22:37:35 yep 22:37:45 Anyway, it should also be possible to *generate* guis 22:37:46 :) 22:37:47 though I'll talk to Njaard about merging artscontrol and Noatun's stuff 22:37:58 even if it means getting my hands dirty myself 22:38:18 Thats also on the TODO (like ... you have an effect which has a parameter, and you know that this has a range from 0..1) 22:38:28 Then aRts should be able to autogenerate a GUI 22:38:35 oh that's interesting 22:38:45 Anyway, unless somebody wants to work on hint-based GUI generation, it will not be in KDE2.2, I guess 22:38:49 eep :) 22:39:05 sadly 22:39:06 he's alive ;) 22:39:26 I suspect that after some docs are written, momentum will grow for things like that 22:39:39 But anyway, GUIs will be, I intend to make the FreeVerbGUI from aRtscontrol at least available to Noatun in a clean way ;) 22:39:43 I'm going to get more busy before I get less :) 22:39:53 Questions/Volunteers to the GUI section? 22:39:54 Njaard: that's the spirit 22:40:08 but not necessarily KDE stuff :( 22:40:14 Njaard: this is just a division of labor, it's not necessarily a short-term division of labor 22:40:25 since we have little choice, it seems 22:40:25 * stw would like to move to ## aRts modules now 22:40:30 ok 22:40:49 It's pretty much self-explaining, so... 22:41:04 poor Njaard.. this one mentions noatun explicitly 22:41:37 what? :) 22:41:46 seeing no comment on arts modules... 22:42:20 Well, if there are no comments on that one, lets go to ##artsbuilder 22:42:42 No *KDE2.2* here either (not much time ;). 22:42:42 stuff that you should maintain, stw :) 22:42:52 ==> i8degrees has joined #kde-multimedia 22:42:55 njaard: will do when time ;) 22:43:03 s/when/if/ :) 22:43:17 Next is ##artscontrol ;) 22:43:20 we are an unending TODO list :) 22:43:46 Njaard: so that does not differ from other parts in kde ;) 22:44:05 I think arts is moreso 22:44:15 Neil: mETz: except that there are far fewer people qualified to do arts than most of KDE, it seems 22:44:21 Njaard: hehe ;) 22:44:36 it's because the one qualified person writes no documentation [cough] 22:44:45 Neil: yes, all those realtime-problems 22:44:58 * Neil suggests a move to ## arts control 22:45:03 stw: wait :) for item 4, prog. wave, what's needed? Is this the reason audiocd performance is bad? 22:45:10 ah 22:45:33 * Neil moved too soon 22:45:39 stw: rikkus talks that you new and delete stuff frequently in arts 22:46:00 Neil: sorry :) 22:46:04 ach: thats about playing 600mb wave files 22:46:06 ach: don't be 22:46:18 ok I have to go 22:46:20 ach: or rather playing a piano from a 1gb sample CD 22:46:39 ach: there you want to cache the beginnings of the samples and not the ends 22:46:49 ach: and of course you don't want to cache the whole sample 22:46:57 * Neil thinks this should have been called an arts meeting rather than a KDE multimedia meeting :-) 22:47:00 ach: artsd currently always caches the whole sample (if it caches) 22:47:24 neil: sorry ;) 22:47:45 heh 22:47:47 Well, I have to say it now or it won't be said, Kaboodle in kdemultmedia for 2.2.. good idea? 22:48:14 Neil: mine does not play anything when getting a part of konqueror 22:48:23 the only objection raised on the mailing list was fixed by the objector 22:48:31 Neil: mETz: in an html file, you mean? 22:48:52 or just embedded viewer by itself? 22:49:11 Neil: noatun doesn't do mid yet, though 22:51:29 we need a timidity playobject 22:51:38 Njaard: yes we do 22:51:38 then kmid can use that instead 22:51:53 my soundcard doesn't do hardware-midi atm :/ 22:51:57 Ok, from my part, we can cut short the rest of the aRts TODO list now... 22:52:22 konqueror should be an noatun plugin too 22:52:27 Njaard: LOL 22:52:31 So: any more questions to the *rest* of the aRts TODO list, or comments 22:52:42 /opt/kde2/share/apps/noatun/njaard.plugin 22:52:46 * stw looks around 22:52:49 artscontrol -> mixer 22:52:58 only hardware-mixer? 22:52:59 kmix should support arts 22:53:08 jep, agree 22:53:17 stw: metz: no, what I wanted to do is actually a software mixer 22:53:23 schimmi: you liked that comment ;) 22:53:27 stw: ah, now it's getting interesting 22:53:29 stw: metz: like having channels, and equalizers and effects in that 22:53:45 stw: metz: it's trivial to do, at most 1000 lines of code for the complete thing 22:53:52 stw: metz: all infrastructure is already there 22:54:08 stw: metz: it will be able to work with all applications which output sound via aRts 22:54:27 stw: metz: so you'd like to work on that? 22:54:41 I'd love to help doing decent UIs 22:54:57 I think I'm rather good in doing dialogs normal-user can use 22:55:28 schimmi: mETz: are you interested in creating a kmix/artscontrol combination? 22:55:38 stw: metz: are you good enough at programming to implement these dialogs yoursel? 22:56:05 I could try to build a gui around methods, yes 22:56:09 schimmi: mETz: I would really like to create a proper mixer app and I think this control stuff should go into one application 22:56:39 I haven't done much except building a GUI around other functions yet. 22:56:40 stw: metz: ok, I suggest you something 22:56:56 stw: metz: you make a GUI of a mixer 22:57:03 stw: metz: and send it to me 22:57:11 stw: metz: and I'll make it actually mix anything, ok? ;) 22:57:15 ok 22:57:20 why not 22:57:43 and if it still sucks we'll surely find people having good suggestions :) 22:57:53 stw: metz: ok ;) 22:58:22 schimmi: do you suggest merging kmix and artscontrol? 22:58:40 stw: I would like to see an app like that 22:58:51 Milk Chocolate is still the second favorite UI :) 22:58:57 people actually like kjofol! 22:58:57 schimmi: instead of kmix and artscontrol or additionally to both? 22:59:01 stw: the arts mixer could be just another mixer plugin 22:59:22 stw: additionally in the beginning 22:59:38 stw: if it has grown up we might drop kmix and artscontrol 22:59:43 schimmi: I don't think the aRts mixer behaves the same like other mixers 22:59:45 we still should keep a standard-kmix 22:59:50 stw: why not? 23:00:01 schimmi: because for instance you can insert effects 23:00:25 schimmi: you need to assign clients to channels (conventional mixers have a "client chooses channel" scheme) 23:00:59 stw: ok, but a client resembles another mixer, doesn't it? 23:00:59 schimmi: so I am not sure if it can be done ideally as "kmix plugin" with the same GUI that kmix has 23:01:27 schimmi: a client might be quake 23:01:32 stw: the kmix successor should be able to display dynamic mixer channels 23:01:33 schimmi: for instance 23:02:09 stw: the quake channel is just another mixer channel and gets displayed dynamically 23:02:51 oh, sounds really interesting :) 23:02:53 stw: I'm sure that can be nicely integrated 23:03:11 hmm, a list with sliders, hmm 23:03:18 * mETz starts visualizing his ideas 23:03:18 schimmi: just one question, what would be the plugin api like 23:03:31 schimmi: QObjects? DCOP? plain C++? MCOP? 23:03:47 schimmi: mETz: QObjects 23:03:56 schimmi: s/metz/stw/ 23:04:15 stw: there would be a MixerProvider or something like that 23:04:30 stw: it will remove/delete mixer channels dynamically 23:04:44 schimmi: the mixer GUI will be dynamic, too, btw 23:04:44 stw: imagine one for oss and one for arts 23:04:46 i'm just throwing out a quick non-researched comment, why can't we standardize everything on sdl? =) 23:04:59 non researched huh? ;) 23:05:02 stw: yep 23:05:04 hehe 23:05:29 <== tranter has quit [using sirc version 2.211+KSIRC/1.1] 23:05:31 schimmi: mETz: are you interested in help out with the mixer project? 23:05:37 i8degress: quick answer: because SDL has an S for SIMPLE and they will just make simple media access 23:05:47 Njaard: its yet another dependency for kde, but neil wrote an artsd thing for it, and sdl provides sdl_mixer, smpeg, etc. sdl_mixer can provide midi, ogg, etc right out front 23:05:57 stw: ah 23:06:15 schimmi: designing the gui: yes, doing more: heavily depends on if I come to a point where I understand that stuff :) 23:06:48 schimmi: mETz: we will find a lot interesting stuff you can do, I'm sure! :) 23:06:58 schimmi: I have no problem whatsoever with artscontrol being ideally replaced by kmix 23:07:07 schimmi: I start to love the qt-designer 23:07:16 schimmi: the problem that I have is that artscontrol internally builds on MCOP as component technology 23:07:40 schimmi: i.e. effect interfaces, gui access, plugin loading and so on should be mcop like 23:08:03 schimmi: that is, the glue that keeps the thing together should be mcop 23:08:05 stw: maybe I'm misinformed what artscontrol can do :) 23:08:21 schimmi: maybe not ;) 23:08:46 schimmi: but ideally artscontrol is a frontend to aRts technology 23:09:01 schimmi: which happens to be able to do a mixer, to do midi, to do synthesis and so on 23:09:12 schimmi: to do effects ;) 23:09:38 schimmi: so the ideal frondend should be similar in scope 23:10:52 stw: I will try to get together a design for a new mixer during the next weeks, we will see whether it fits to replace all what artscontrol can do 23:11:08 * mETz has a really cool idea for > 2 channels 23:11:18 schimmi: you are not going to do the interface in idl, will you? 23:11:20 s/weeks/week/ even :) 23:11:58 === WildFox is now known as Wild|zZz 23:12:05 stw: I thought about a noatun like plugin system with some abstract base classes. maybe kpart based 23:12:10 === Notify: WildFox is offline (pohl.openprojects.net). 23:12:40 <== i8degrees has left #kde-multimedia 23:12:48 schimmi: i.e. a MixerClass, an EffectClass, an ... ? 23:12:55 stw: idl will be overkill here 23:13:05 stw: yep, something like that 23:13:12 schimmi: its not 23:13:24 schimmi: I mean, whats the *cost* that you are trying to avoid by not using idl 23:13:39 stw: why should I? :_ 23:13:39 ) 23:14:10 schimmi: suppose you specify Arts::MixerChannel as IDL 23:14:19 schimmi: then you can have MixerChannels inside artsd 23:14:26 schimmi: and talk to them from kmix 23:14:49 schimmi: other control-like apps (like gartscontrol for instance) will access the same MixerChannel objects 23:15:00 schimmi: hmm 23:15:20 stw: I will look into it during the next days 23:15:31 schimmi: that way, you'll for instance be able to update the volume one Arts::MixerChannel has (via change notification) in kmix once it is changed in gartscontrol 23:15:35 schimmi: just as example 23:16:14 schimmi: currently, if you start two artscontrols, and turn down the volume in one, the other will not notice 23:16:23 no polling trough a timer anymore or what? 23:16:38 stw: I thought about doing a QObject based plugin system. The binding to arts is just a "little" detail of the arts plugin ;) 23:16:47 schimmi: thats bad (i.e. they are independant of each other, and do not access the same StereoVolumeControl thingy) 23:16:54 stw: of course I will add notification stuff 23:17:09 schimmi: I know that 23:17:33 schimmi: the problem is that we're not lacking an oss mixer but an aRts mixer 23:17:36 schimmi: mETz: no, only if the low level layer doesn't support notification 23:17:50 schimmi: and this problem will not go away if you add another layer of abstraction on the top 23:18:15 stw: is there no low level arts channel api yet??? 23:18:23 mixer channel api even 23:18:33 schimmi: no there is no mixer channel api in aRts 23:19:14 stw: is it possible to get and modify the effects stack of the running applications? 23:19:26 stw: not only the global effect stack 23:19:30 schimmi: no 23:19:38 schimmi: there are no per-application effect stacks 23:19:45 stw: there has to be a way to navigate the global effect tree 23:19:49 schimmi: at least not in a standarized form 23:20:07 njaard: you mean the complete graph inside aRts 23:20:12 njaard: that would be nice, yes ;) 23:20:17 yes :D 23:20:55 schimmi: all that aRts currently offers works like this 23:21:07 schimmi: applications create a Synth_AMAN_PLAY object and hand the data over to this 23:21:18 schimmi: they add a tag (like "quake") to it 23:21:40 schimmi: you can go to a (global) Arts::AudioManager and assign the destination of Synth_AMAN_PLAY objects to busses 23:22:04 schimmi: so a simple mixer would provide 8 busses, and let the user assign applications to those eight busses 23:22:22 schimmi: but this might not be the optimal approach to mixing, not even the one the user wants 23:22:36 schimmi: (the user may not want to have eight idle channels around if there is nothing to do) 23:23:05 schimmi: so... mixing is pretty much "needs-more-work" in aRts 23:23:20 hmm 23:24:59 schimmi: note that also apps using the C API might want to modify their own volume or the global one 23:25:03 schimmi: like XMMS does 23:25:07 schimmi: arts doesn't do that either 23:25:39 * mETz would highly appreciate seperated volumes for apps 23:25:56 schimmi: mETz: that's what I wanted to implement 23:25:58 I hate to hear mp3 and then my icq makes damn loud "PIIING" 23:26:12 well 23:26:42 * stw notes that eventually somebody somewhen will have to change some line of code for that which might eventually reside inside the kdelibs/arts or kdemultimedia/arts directory ;) 23:26:52 then every app gets its own slider in the mixer and the default volume is as loud as the volume for the thing it does output on (i.e. wave-output) 23:27:27 stw: metz: yes that would be nice 23:27:59 stw: metz: besides, assigning an effect on a per-app base (equalizer/freeverb) would be really nice 23:28:07 stw: metz: and of course scopes and such 23:28:26 hmm 23:28:40 * mETz thinks about popups conatining the effects 23:28:59 hmm, too late to type on a keyboard :) 23:29:47 Where do I get docu about what arts at the moment can do exactly? 23:30:22 Me, as a user, only saw some effect-plugins and multiple waveoutput at once 23:30:44 stw: metz: go to http://www.arts-project.org, all documentation that exists is there 23:31:13 stw: metz: there is the handbook, kdoc generated idl references, the things that are in kdelibs/arts/doc 23:31:22 stw: metz: all that should be somewhere on arts-project.org 23:31:26 ok 23:31:43 It's better to know about what to write for ;) 23:32:46 Ok, I guess the moderated part is over now. 23:33:00 not too many left anyway 23:33:17 ;-) 23:34:02 Version 1.00.09 23:34:02 Last updated: 23/02/2001 23:34:09 hehe, that's gooood 23:34:22 * mETz reading arts-handbook 23:35:03 stw: metz: yes, it's pretty up to date ;-) 23:35:41 btw, has anybody a complete log file? mine is a bit split in two half parts due to the network problem... 23:35:42 This task fits well into my actual project 23:35:59 * mETz hates buffers being too short 23:36:05 but it has to be somewhere 23:36:06 wait 23:36:42 yes, I have one 23:36:44 50kbyte 23:36:58 stw: metz: can you dcc it to me?