IRC log started Tue Sep 4 21:13 > ok, I think we start but as you know, no pc :( good > at special impatience of wildfox, I'll move his item to the top > thats basically #1 Making the MCOP component model more open to the world (thnx, 10$ come later) > so we've got a dcop to mcop bridge by wildfox, which is hopefully soon able to do dynamic gatewaying a day after i got my pc back, hopefully > we've got jmcop, too kool does #1 just involve an mcop->dcop bridge or are other bridges planned in the "opening"? rambokid: java too *** MindWar (linuxgurun@fysgr292.sn.umu.se) has joined channel #kde-multimedia > so, I am quite happy about that dcop/mcop thing, and I think its okay if we write in in the kde3 plan * stw hands the responsibility for finishing this over to wildfox yes > wildfox: how did you say... people really gotta do things if we write them in the plan extremly important s/do/finish/ Neil: even better! > wildfox: so ... you'll really need to do it ;) - and right - with dynamic things and such ;) heh ;) #kde-multi MindWar H linuxgurun@fysgr292.sn.umu.se (Andreas Burman) #kde-multi gogo H robert@Ae2db.pppool.de (Robert Gogolok) #kde-multi malte H xray@reports.any.kind.of.netabuse.de (Malte Starostik) #kde-multi ach H ach@ds10.xray.mpe.mpg.de (Achim Bohnet) #kde-multi berkeley H mseiwert@pD95158FE.dip.t-dialin.net (Michael Seiwert) #kde-multi mvogt H mvogt@aixd1.rhrk.uni-kl.de (Martin Vogt) #kde-multi pansen H wuerthne@wuerthne.desy.de (sirc user) #kde-multi Shyru H daniel@pD9E3A7BE.dip.t-dialin.net (Daniel Haas) #kde-multi stw H stefan@p3EE06587.dip.t-dialin.net (Stefan Westerfeld) #kde-multi linuxdewd H linuxdewd@w081.z208177180.chi-il.dsl.cnc.net (mumuletz) #kde-multi Vir H mkretz@pD9E3AA06.dip.t-dialin.net (Matthias Kretz) #kde-multi WildFox H wildfox@p3EE0FA8A.dip.t-dialin.net (Nikolas Zimmermann) #kde-multi Neil H usr274@ip-20-249-205.la-l3.navipath.net (Neil Stevens) #kde-multi rambokid H timj@hmbg-3e35ad55.pool.mediaWays.net (Tim Janik) MCOP->DCOP Bridge (Nikolas Zimmermann) living in Cologne ;) need an address and phone number for remote harrassment heh lol > good - oh UCOM - I wrote it there because it would be cool to do scripting with the standard qt scripting dynamic dispatching thing * Neil being 9 time zones away can make middle of the night calls easily > anybody wants to look at that? +49-170-4136xxx * WildFox looks at master-malte malte: waaaaah ;) * stw thinks its not soooo important if we have dcop thing, though he lies! * Neil agrees with stw, but oh well :-) +49-190-62626262 * malte didn't look at UCOM yet ewww ab 99 pfenning, bist DU dabei ;) WildFox: you're not 18 yet, not allowed to call there. but let's stop this * stw didn't look at UCOM either - but well, it might be the component model of the future malte: hehe ;) malte: win't do UCOM? stw: might, might Neil: Universal COmponent Model > neil: well, listen to mattias ettrichs talk about components as ogg anyway stw: buy me a T1 for my home and I will :-) > neil: but of course, it stands and falls with real interoperability, like gtk components (hey rambokid) *** schimmi (sts@p3EE21298.dip.t-dialin.net) has joined channel #kde-multimedia hi ah schimmei Well, I don't get hyped about the component model of the year :-) * stw points everybody to http://space.twc.de/~stefan/kde30.html a last time > neil: well lets see > so .. anything left - otherwise I'd like to move to the next point * stw moves to #2 Compatibility with legacy/broken OSS drivers yes, keep it moving ok guys, just 2 hours inet left for the next 3 days my dads _needs_ inet :( what is that threaded OSS patch? > well, the primary source for bug reports aRts gets (and thus for frustration) are problems with the driver i wish you all a nice day, and please log this session cu > malte: the threaded oss patch is a patch that opens the driver in blocking mode and spawns a seperate thread *** Signoff: WildFox (Leaving) > malte: it works kind-of well, even on my totally broken laptop where xmms works and artsd doesn't really, it improves performance *a lot* > (less dropouts more reliability) > I am currently mailing around with Matthias to integrate it cleanly (currently has a root exploit left to fix ;) hmm, don't know nothing about that stuff... The select(..) is responsible for the dropouts ? *** Shyru has left channel #kde-multimedia > mvogt: yes, it seems so - some drivers don't support select(..) properly, or at least not in the same quality Well, HEAD is allowed to break if the experimental patch doesn't quite work perfectly, but will be better in the long run, just put it in and go stw: do the benefits steam from opening /dev/dsp blocking, or do they actually come from artsd sending the thread sample data and thus introducing an extra buffer which covers up for latency issues in arts main thread (such as network io)? > mvogt: on the other hand, the patch allows to increase the latency by software by buffering, that also helps especially for drivers which have a small buffer stw: i'd be surprised to see having/not having O_NONBLOCK make a huge difference Its the blocking thing. The buffer does not make this better. I had some time ago a test for that > rambokid: yeah, but you know how surprised one sometimes can be about linux drivers ;) > anyway, it helps > and it will be optional (because its not good at doing low latency stuff), so it will be just-another-option Can we make it default :-) > mvogt: we'll see - if it works really really well, maybe stw: very low latency is the standard user requirement xmms uses blocking and has no dropout up to load of 6 > mvogt: otherwise, I think it might help if we setup a how-to-get-artsd-running-with-my-soundcard-page but when you say that the threaded driver doesn't allow for low latency, that sounds a lot like the extra buffering involved just coverin up for main thread latency issues or just get templates into kmail, and prepare a bug-closing template that says "Driver problem. Fix your driver or get better hardware." :-) well there is still the "threads make problems != linux" which soundcard doesn't work well with arts ?? mvogt: all of KDE uses threads in KDE 3, so those problems should go away > berkeley: aureal for instance - horribly broken driver As I understood, the thread problems were caused by mixing threaded and non-threaded code ensonic too i think es1370 works fine here * stw asks more clearly: does anybody *volunteer* to set up a driver - compliance page for artsd? Neil: yes. I always wondered why it actually works (qt-arts linked again pthreads etc...) malte: es1371 has problems > berkeley: it has not > berkeley: I am using this card so per definition it works flawless ;) :) maybe this one I use is broken I'll check berkeley: i got an s1371 as well, and it had issues i only had problems with the early 2.4.x kernels > ok ... anyway ... move on? still some points to do? where /dev/dsp would just block on any access move on > good * stw moves on to #3 i18n > it's horrible - w.r.t ui standards - that artsd error messages are still english in a complete russian kde what exactly is the problem there? * Neil thinks i18n is a sign that perhaps arts needs to be in its own module, that kdelibs depends upon > malte: the problem is that artsd can't use i18n("fooo") anywhere because it doesn't know about kde-ish i18n can't you link in kdecore? > neil: we'll talk about that later, but yes stw: am I right in assuming you don't want arts to depend on kdelibs? :-) > malte: no, I would like to keep artsd reasonable independant to make it possible to let it become standard beyond the kde desktop therefore arts will use its own i18n, therefore it probably shouldn't be mixed with the rest of kdelibs * stw thinks of gnome users using artsd for instance right * Neil would hope it stays in kde cvs though :-) > anyway, that *has* to be fixed before KDE3, and has jeff has already told on the list he would like to care about it, I'll guess it will happen stw: you can put all strings in a header and then do the error logging in a seperate lib. (linked against the comile time i18n suport or against define i18n(x) x *** carsten (mannfred@p3EE24D5F.dip.t-dialin.net) has joined channel #kde-multimedia maybe if the message command is artsmessage, pass format strings and arguments instead of the formatted message and include all strings into artsmessage with I18N_NOOP? > mvogt: yes, but there are also things like Synth_FREEVERB which write strings on the screen using the toolkit abstraction layer #kde-multi carsten H mannfred@p3EE24D5F.dip.t-dialin.net (Running on RealityX 2.0.1) and then what do you do about third-party translatable things? hmm so use libc's i18n functions? wouldn't that be a nightmare encoding-wise? > malte: well, couldn't they be utf8 transported to the gui? Well, one could port locale stuff from kdecore > anyway, I think jeff will be able to do this - if you have ideas, just discuss those issues with him once things are being implemented * stw moves on to #4: Recording recording! yay! > so, actually I think it's pretty important to get that right finally > can't have a sound server which can't even record too bad rik couldn't be here.. he was so interested in that > the artsc API still returns E_NOIMPL or something until your mail about that i didn't even know arts can't record yet.... > that one is quite important, too, and I doubt that I'll have too much time to care about it > anybody want to take over this? can't :( > neil: well the problem is that rikkus said: yes we need that, and oh not finished? - then I'll wait until it is done ;) for me recording is not so important ...:) > malte: too little time or too little know-how? * stw can help out with know-how ;) stw: both, and a broken line-out from my stereo, so no real source either for testing... malte: you could record realplayer using artsdsp > malte: thats not an argument - at least not too strong - you could play an mp3 in artsd, and record it over the recording interface from a wave editor hmm, true > vir: or do you want to do it? > vir: you will be doing server-to-server streaming anyhow, right? I wanted to do some other things ;-) OK I take a look how much is it? but the no time part is rather important, i'd like to get some order into things i started and didn't finish yet thanks Vir :) > vir: well, there is somebody who wants to write the front end (I can give you the email adress) > vir: and there is a kind-of working implementation in csl ok > vir: so if you do server-to-server streaming, it should be ok I'll do it > (not too hard, that is) > vir: I wanted to suggest wildfox to write a KAudioStream class that wraps recording/playing in a nice kdeish interface It'd be nice not to have to use soundstudio :-) > vir: he isn't there now, but I think he might want to do this (he likes libartskde a lot ;) not that I have the knowhow or time to commit to finish that I'll talk to him > ok, thats done * stw would like to move to #5: video embedding * stw would like to move to #5: video embedding and streaming, that is video embedding. yes i'd be interested in the API of that one, to integrate it into realmedia_arts, which i'd like to get into shape for kde 3 working on that. I will provide a general track type for Brahms to allow video-editing as a plugin pansen: no. this does not work stw: is this about 100% porn compatibility in artsd? ;) why not? pansen: which codec should do that. we have _no_ support for "single image delivery" Well, VideoPlayObject is in > rambokid: it's rather about klicking on videos of bees and flowers in konqueror and not having to pop up a seperate window ;) and doing preliminary embedding in kaboodle any work should extend that * Neil speaking for the absent WildFox I don't know, I will only provide the framework, I think Vir was interested to implement the video editing VideoPlayObject was just a proof of concept that got put in anyway > neil: well, I think its all right for now pansen: not yet - I'm not up to it yet > neil: it's using the X11 embedding interface, thats what gstreamer for instance does, too > neil: and we need *some* solution for getting for instance realmedia embedded in konqueror pansen: ah ok. But as I see it, there is no codec who can do this currently. Maybe ffmpeg, but I didnt look closer at the API > mvogt: why not? whats wrong with synchronizing only on time, and embedding the X11 output? stw: no embedding will work, but for _video editing_ we need support for "frame control" As I understood it, we use the aRts-API, whatever codec aRts offers... > mvogt: right - its not good enough for video editing *** wicky (wicky@CC11277-a.ensch1.ov.nl.home.com) has joined channel #kde-multimedia pansen: Well, this is about deciding how arts will provide them :-) > mvogt: I would really love to see video editing in aRts interfaces, too, but seriously, I lack the time to do it pansen: for video editing there must be an API which says: jump to _frame_ X stw: we need _some_ things for that. (timestamps in arts) and structured data delivery. > mvogt: we have that with seek and customUnit(frame) in the Arts::PlayObject API > mvogt: but you're right, it would be better if somebody with the necessary know how added some things to aRts for that stw: the method is specified rather easily. I mean the _implementation_ stw: erk, is video something that might need to run through the engine as well? stw: we need the following. I would call this "frame based delivery". We deliver frames with a StartTime and endtime. > rambokid: no, I don't think it should stw: currently we have only the "unstructured" float* left float* right *** Signoff: schimmi (Read error to schimmi[p3EE21298.dip.t-dialin.net]: EOF from client) > rambokid: you're messing up the audio streaming with big-chunky-video frames > mvogt: we also have DataPacket *packet stw: if that's to become a possibility even in the not so near future, we need to know it know. since basically, you'll need to be able to run two engines in the same process for that stw: huuuu. A bit too unstructured. > rambokid: you only do synchronous streams with the engine, I'd suppose *** schimmi (sts@p3EE21298.dip.t-dialin.net) has joined channel #kde-multimedia > rambokid: video is a packet-like service stw: yeah, but maybe someday, people will want to combine video streams (overay) or filter them etc.. *** jordi-boehme (jordi-boeh@pD95309DA.dip.t-dialin.net) has joined channel #kde-multimedia overlay i meant stw: and audio must become a packet based serve too IMHO. nick jordi-boehme_de sorry > mvogt: we can provide a gameway from packet-like things to "synchronous" streaming I plan to to the embedding thing with a new lib. *** jordi-boehme is now known as jordi-boehme_de > mvogt: but I will rather give up coding aRts than getting rid of "synchronous" streams > mvogt: you need them for all music-like apps > neil: anyway, what is the state of noatun & video embedding? stw: Noatun? I don't know, and don't expect it to happen really > neil: why not? Well, it'd mean changing every single UI plugin adding a feature that the app really isn't optimzied for > neil: thats baaad > neil: I think there is a "market" out there for a player that supports both: skins and embedding video > neil: and kaboodle won't be it, as far as I can see Well, fact is, Noatun is optimized as a music player Every single decision charles makes optimizes it further in that direction and I don't disagree with that Neil: the embedding thing looks rather easy. today I embedded an video with the qxembed class. It only need the X11 Window ID. It was really easy. If someone wants to fork kaboodle to add skins, the licensing allows that, but don't expect skins in kaboodle mvogt: but you have to add that to every single UI plugin and what do you do if multiple UIs are loaded? > neil: I think embedding works already in kaboodle, doesn't it? stw: yes, in HEAD now > neil: loading multiple UIs is one of the biggest flaws of noatun, afaics use kaboodle embedded in konq, and it will swallow mpeglib > mvogt: see? works already, with your code ;) well, Niko's patch patched mpeglib along with kaboodle and arts :-) Neil: well embeding can just mean "controlled by QT Widgets" It does not need to be in the noatun app. I didn't like that there are now "popup menu" support for that. sorry, brb *** Signoff: malte (Read error to malte[reports.any.kind.of.netabuse.de]: EOF from client) *** malte (xray@reports.any.kind.of.netabuse.de) has joined channel #kde-multimedia mvogt: I don't understand You'd have the video plugin create its own UI? Currently (before the current embedding patch) you cannot have a popup menu. because I have no controll over qt. with the qxembed this works. > neil: indeed a possible solution might be that *some* noatun plugins support embedding with special magic code, whereas others open an extra window > anyway, I think we should talk about this when charles is there... stw: yes, that's just a noatun-specific detail I just don't expect it anytime soon since I won't do it, and I have no idea if/when Charles would do it and with all the patches Charles loses/reverts, I wouldn't blame anyone else for being wary > neil: I see, I hope that can be mended > neil: the alternative - starting from scratch with yet-another-media-player - doesn't sound too promising * stw can't imagine anybody being happy with three media-player-like apps heh when it took enough badgering to get a second one in kdemm :-) a third one would take years to get moved > neil: right, unless we throw two out, and put that one in we still have kscd Anyway, I see kaboodle replacing aktion what's wrong with an aktion-style UI? > neil: nothing, it's just not faaanncy ;) if your priority in designing an app is "skins" rather than usability and standards, then I think your priorities are messed up KDE apps are supposed to be showcases of KDE standards let skins be third-party > neil: *my* priorities are different, I can live without skins, but that doesn't mean that users can You know what? > neil: even m$ and apple do skins-in-players nowerdays > anyway ... I'd like to move on If one app would provide them with every non-free codec they wanted, I think users would deal with a tk UI So if you want users, get more playobjects :-) *** Signoff: berkeley (farmer.openprojects.net sagan.openprojects.net) *** Signoff: jordi-boehme_de (farmer.openprojects.net sagan.openprojects.net) The number one codec asked about on #kde-users is divx * stw will try to sort out the media player issue on kde-mm or in a seperate meeting mvogt: any chance of merging that into kdemultimedia? patents * stw moves on to #5: PlayObjects (special point ;) * stw moves on to #6: PlayObjects (special point ;) ffmpeg look promising > I had a mail today of somebody suggesting gstreamer playobject and I want to try a xine port->PlayObejct as soon as the new X11 lib is ready * Neil can't find that point on the list stw: what, jus tlike mvogt proposed ages ago? :-) > neil: well, thats one of those "I forgot it in my mail" points mvogt: if you do a custom dvd playobject I'll do a ui for you, if you like subtitles, audio, all that custom stuff The problem is integratin xine in the PlayObjects. Currently this is too much work. Charles was saying at one point he'd volunteer to do one as soon as there are nice wrappers this will be easier. but has backed out :-( s/volunteer/take a DVD drive from me as payment/ most likley because of the sync,thread,deadlock+ etc.. problems mvogt: would any hardware upgrades make it easier on you? RAM, a new drive, a disc or two? btw: The vob plugin for mpeglib plays unecrypted vobs * Neil noticed they probably had to be unencrypted... :-) There are other problems: I thing we cannot put these codecs in kdemm > mvogt: legal issues again? > malte: what about the realplayer thingy btw? we need a server in a software patent-free country I have to go. Bye dvd = mpeg2+ac3+deccs. If you do that make sure not to travel to USA (DMCA) stw: no idea about the legal status, still no further replies :( technically nothing new either, i didn't really have time to code since linuxtag *** Signoff: pansen (Read error to pansen[wuerthne.desy.de]: EOF from client) > gstreamer anyone? stw: xine is more interesting. > ok - I just made a list, which reads > ffmpeg, xine, libmpeg4, gst, realplay libmpeg3 that's in kdenonbeta, but I can't get it to compile and it crashes for Niko Neil: not active developed stw: that playobject and maybe some infrared stuff (generally KDE, but maybe mm-apps will use it the most) are the mm-things on my TODO so far > mvogt: maybe you (or somebody else with experience about this) could send me a statement about what it can do, how the current status is, and so on, I can put in the kde30mmplan? -lilo- [GlobalNotice] Hi all. Once more into the breach. In case you're wondering, we killed a cracker channel yesterday. The new code should be a lot cleaner, but scheduling has been a problem. Thanks. OH -lilo- [GlobalNotice] We'll be coming back up in a moment, with the attendant temporary splits. *** Signoff: ach ([GlobalNotice] We'll be coming back up in a moment, with the attendant temporary splits.) malte: heh.. your IR stuff should probalby be kde-wide, and then just use Niko's dcop->mcop bridge Neil: something like that yeah *** Signoff: schimmi (zelazny.openprojects.net farmer.openprojects.net) *** Signoff: linuxdewd (zelazny.openprojects.net farmer.openprojects.net) *** Signoff: Vir (zelazny.openprojects.net farmer.openprojects.net) *** ChanServ has changed the topic on channel #kde-multimedia to The KDE Multimedia Channel *** linuxdewd (linuxdewd@w081.z208177180.chi-il.dsl.cnc.net) has joined channel #kde-multimedia *** Vir (mkretz@pD9E3AA06.dip.t-dialin.net) has joined channel #kde-multimedia *** schimmi (sts@p3EE21298.dip.t-dialin.net) has joined channel #kde-multimedia guess I can reuse some of the code in noatun's lirc plugin for that > ok, anyway, I'd like to move on Neil: I'd love to get noatun and kwintv (once I'll switched from xawtv) to coexist with one remote and don't react both at a time to the same buttons... * stw moves on to #7: MIDI *** ach (ach@ds10.xray.mpe.mpg.de) has joined channel #kde-multimedia > well, midi - I would like to get rid of libkmid and make it possible to use aRts as sole and single provider for midi output > thats especially interesting for sequencer apps - all of Brahms/Rosegarden/Anthem are probably going to have full aRts support > so they kind-of expect that ;) > (but well, it seems that there is not much to talk about this one, especially as the only one who needs that, pansen, is gone already ;) > so, I'll just *do* it, ok? ;) heh stw: sounds cool ;-) * stw would like to move on to #8: GSL Engine > everybody read the verbose section about that one? questions to that? yes.. you're sure there'd be no glib dependency? :-) Neil: yes good good once a couple of apps are gone I'll be nuking that lib from my system, I'd hate for arts to make it have to stay > neil: oh well, rambokid is a glib maintainer, so he'd probably know how to write the engine in a way that it can be made glib-free ;) > well, anyway, the engine is really cool for really low latency apps, supports threading in all plugins, and well all that is in the mail > I think it should be possible to get the integration done in a nice and clean way, I'll probably start committing the thing very soonish the only thing i didn't get is: what tasks does the engine do exactly? what does it replace in arts? > malte: basically aRts has an algorithm for walking over the modules and telling them to calculate data > malte: that is triggered whenever the soundcard needs more data yeah > malte: the engine provides a new implementation for the algorithm (to be very brief) in a way that it can > malte: - run in a seperate thread from the aRts main thread *** berkeley (mseiwert@pD95158FE.dip.t-dialin.net) has joined channel #kde-multimedia ah, okay > malte: - support calling calculations in more than one thread > malte: - support features like feedback loops > it might also be more efficient (or so I hope) than the old algorithm, which heavily relied on cluttering up the stack with recursions This meeting is a lot less pessimistic than I expected after reading the "Why artsd doesn't work" mail in reply to Charles :-) > neil: heh ;) > so... ok, the engine is another: trust me, I *know* what I am doing, its cool, we need it, and I'll *do* it thing ;) - or rather rambokid and me to be precise > so we can move on to the next issue, which is * stw moves on to #9: GSL other stuff > still GSL - basically there is quite some smart code in there, the long desired wave cache (for partial wave loading) > and filter design code for all kinds of filters (we still got no highpass) stw: so would that improve apps like kjezz, that play the same file over and over? > (as Arts::Synth_HIGHPASS) bounce, bounce, bounce > neil: not really - those things are already cached oh they are? hm > neil: the shortcoming about the cache was that it always loaded the whole file at once > neil: which is bad if you are playing a large file (300M) > neil: there have been quite a few bugreports about this one, too, and the favourite hack has been to use the mpeglib WAV loading code instead of he aRts one > neil: which works reasonable, but on the other hand has no caching at all > neil: so that one is for playing lots of samples efficiently (as in music symphonies) * stw has found a way to move to #10: samples Because we had a couple complaints about kjezz so I wasn't sure .. > neil: well, it might be that it creates a PlayObject, I'll write that down to my TODO list and check it, ok? no, I checked, it's not doing anything fancy like that > neil: does it use knotify? > neil: or kaudioplayer? * Neil invites schimmi to step in :-) * Neil pulls up the file * schimmi is triggered by his name m_artsServer->play( path.latin1() ); that's what it does > neil: basically that should get cached I assumed schimmi of all people would do the right thing so I just let the matter drop until now :-) ok > neil/schimmi: ok, if you provide me with an strace showing that artsd loads the file multiple times, I am guilty, otherwise, there is nothing we can do ;) enough sidetrack let's move on :-) * stw moves again to #10: Samples I'll ask the next user who complains of slow kjezz to do that what do I have to do with that? :) ah, ic > Samples. > I think synthesis is nice for music production, but not sufficient. > It would be nice to address this - I have written a .PAT loader, there is a AKAI loader and finally GSL loader > the .PAT-loader will for instance allow you to write a timidity-style PlayObject for aRts > which would be nice (doing the same thing as kmidi, then) d'you know if there is any docu on awe sound font files? /me has some old ones of them... : ) > malte: there are loaders in both, timidity and MuSE, so I think you could figure it out > malte: but there might be also documentation somewhere on the net okay, _maybe_ i'd write a loader for those then > malte: that would be cool > well, so ... basically I don't know if I am going to have the time to care about that for KDE3.0 > so, if anybody feels like helping on the samples front, feel free to do so - it's extremely nice for doing serious music, you know ;) > ok, one more quick point, then, that is * stw moves to #11: environments here I am ;-) I wanna work on this I'm currently look into the mixer stuff how to make insert effects > vir: thats great s/look/looking/ But I want to have a mixer like I'm used to have in the real world > vir: so... should I write you down for "has the primary responsibility to get this right for KDE3?" what is "right"? > vir: sure, we should have master volume and such, too ;) yeah of course > vir: well, right is well - useful, usable, nice, great, ... - whatever What I want is: gain, EQ, Effects, Pan, Fader > vir: yeah, this sound about right > vir: the idea with the mixer is to have it configurable complexity yes > vir: i.e. if you don't have too much CPU, you can use a very simple mixer, if you have lots of it, you can use a very fancy mixer > vir: anyway, we can just discuss design things for the mixer on mail/irc, ok? ok > cool, so we're about done hmm * stw moves to the last point: decisions one thing that's annoying in noatun... > malte: can you wait just one more second ;) I say break BC once, (since GNOME isn't using it yet), bump up the arts version number, and move it out of kdelibs sure sure until other projects are using arts, arts should be able to break BC when KDE breaks BC Neil: sounds like a good summary to me :) > neil: BC is ok > neil: I am also in favour of breaking this breaking BC including renaming all the V2/V3 stuff I'd also prefer removing the V2 stuff > neil: thats wire incompatible fine right? > neil: so KDE2 apps will cease to work in conjunction with KDE3 just killall artsd; in kde 2 before starting up the KDE 2 artsd.. only affects developers > neil: no er.before startign the kde 3 artsd hmm, and if SoundServerV2 stays just as an alias to SoundServer which then contains everything? or will that still break WC? Since you already can't use KDE 3 apps with KDE 2 > neil: you can > neil: you install KDE2 to /opt/kde2 and KDE3 to /opt/kde3 > neil: then you start up a KDE2 app and a KDE3 app on the same system but not in the same session > neil: it should work > neil: waldo bastian says it should work > (see kde-core-devel= *** Signoff: gogo (Ping timeout for gogo[Ae2db.pppool.de]) > malte: well, we could try so well > malte: of course the question is always what would be affected I don't think that one say-so by Waldo is the same as a commitment that DCOP et. al. will stay the same Right now there's no guarantee So it may work now, but it might not > malte: I don't know which KDE2 apps don't use knotify, but rely on aRts interfaces directly well, we just pointed out kjezz that does konq_sound? but that wasn't using V2... > malte: true - so you couldn't run a KDE2 konqueror with sound preview inside a KDE3 session but - who would want that anyway? stw: well, you can get rid of V0 interfaces now, and upon KDE 3.1 do V2->V0 > rambokid: I doubt both > rambokid: there are apps that require a V0 interface, and those will cease to work if they cease to exist stw: But why not take this big opportunity, a major new version, to clean and simplify the interfaces? when only developers will be inconvenienced... Users don't mix KDE versions like that remember how painful KDevelop was for many people? Even developers can hardly do it Is there a single non-KDE app that uses arts directly? > neil: gnome-arts (yet) is that an app, or a lib? *** jordi-boehme_de (jordi-boeh@pD95309DA.dip.t-dialin.net) has joined channel #kde-multimedia > neil: you can get a tarball of gnome-arts, it contains a gartscontrol hm > neil: but anyway, it hardly counts because it's hardly deployed > anyway, I'm going to think about that some more, and will decide it one way or the other * stw thinks that doing it the clean way might be nicest right, if GNOME starts using arts, then arts' BC and WC (we need a new acronym for wire compat.) cycles have to disconnect from KDE compat is not an issue fo rgartscontrol, i need to make sure it compiles against recently released gtk+1.3.7 first Neil: what makes you think only developers? > neil: ;) Neil: in the end, when kde 3 will be out, _users_ won't be able to use both kde3 and kde2 apps simultaneously then malte: Users don't do that.. even Developers had a lot of trouble running KDevelop (kde 1) with KDE 2.0 if developers couldn't do it, I don't ever expect users to do it > neil: users do that and KDE 1 didn't have a whole set of daemons yeah, i'm still for breaking it so it's harder yet for KDE 2/3 > neil: I had a bugreport about kaudioserver-requiring apps not running under KDE2 eww, missed quite a bit due to ksirc bug :( stw: see, since every serious arts app right now is KDE, all that has to happen is to make sure that they all get ported to KDE 3 (too bad Brahms came out so late in the KDE 2 cycle :-) then there are no compatibility issues people will have no need to run KDE 2 apps with KDE 3 > neil: well, Brahms is basically ported already to KDE3, so this time it will be first ;) excellent > ok ... so ... I think here ends the "moderated to the TODO list" part > I'll write a summary about the meeting and post the log, as usual okay, about noatun: even when it's stopped, it leaves artsd busy so it won't suspend > thanks for attending, everybody ;) * stw moves to #12: Open Discussion ;) and keeps hogging cpu for the visualization :( malte: do you have the eq on? AHA no it's the vis does it continue even with the vis off? ah, the kjofol one that is didn't try yet yes, I Was about to say quit using a skinloader then :-) and currently i have no noatun (building kdemm now) it's probably the vis system, since the visualizers are going to be constantly querying for data to output winamp skins do work now shoulnd't be too hard to turn them off when napp->player() is idle should be able to fix that globally even would be kinda nice > schimmi: btw, are you using kde3 yet? I think there is a qstyles issue in kmix > schimmi: I have a patch, but don't know if it is sane well, styles are completely up in the air until Karol gets things ported malte: so was that your noatun complaint? or have you more? nah, that's all :) heh good > oh, apropos, anybody knows if there is an equivalent to setPalettePropagation( QWidget::AllChildren ); > (kmidi fails on that currently) hm it was just rather annoying to be forced to quit noatun (as artsdsp netscape just SEGVs), 'cause it takes so long to startup with my playlist :) * Neil wonders what Charles will have to say next week re: my video/noatun comments malte: say what? :-) *** jordi-boehme_de has left channel #kde-multimedia (KVIrc: a breath of fresh net...) malte: how big is your playlilst? + wc -l /home/malte//Docs/Sounds/all.tronplaylist wc: /home/malte//Docs/Sounds/all.tronplaylist: Datei oder Verzeichnis nicht gefunden you just entered into my domain so my interest just heightened (since I'm pretty sure you use tron) err > malte: you can prevent the artsdsp netscape segfault btw ha + wc -l /home/malte//Docs/Sound/all.tronplaylist 3310 /home/malte//Docs/Sound/all.tronplaylist by not using netscape :-) 3308 entries???? wow ~> wc -l media/mine.tronplaylist 458 media/mine.tronplaylist > malte: if you need that, build artsdsp against libmcop, but not against libpthread - I didn't investigate this further, though, because I don't know if it really helps * Neil tries making a few copies of his list to test heh, konq won't work on that site (js) and as it's for ordering pizza, i won't stop going there ;P stw: ah thx, will try that some time not that i insist on the sound, but netscape would hang otherwise :( > malte: its also still an open bug on bugs.kde.org - maybe including a Makefile.am rule for building artsdsp twice once with threads and once without would help, but I'd first like to hear a "success story" ;) > btw, what might be a nice KDE3 feature, too, would be adding a checkbox in .desktop files for enabling artsdsp yeah! > telling people with no command line knowledge to *simply use artsdsp * is a bit ... well, user-unfriendly ;) *** Linux2001 (Linux2001@pD957F92E.dip.t-dialin.net) has joined channel #kde-multimedia *** Linux2001 is Linux2001@pD957F92E.dip.t-dialin.net (Sven) *** on channels: #kde-multimedia #koffice #kde.de #kde-users #kde-women *** on irc via server niven.openprojects.net ([127.0.0.1] Phoenix, AZ (T3)) #kde-multi Linux2001 H Linux2001@pD957F92E.dip.t-dialin.net (Sven) ~/media> wc -l test.tronplaylist 14138 test.tronplaylist let's see how this works stw: i don't quite get that, you also have just one libc on your system, either with or without threading. that same mode should work for artsdsp as well, shouldn't it? whoa * Neil suddenly sees what malte means ok this has to be a QDom thing > rambokid: I think it has to do with preloading though if I'm using KListView inefficiently it might be that patches welcome :-) > rambokid: if you have libc, it defines some symbols, that are also defined in libpthread > rambokid: so basically, if you link your app against libpthread, then those symbols get used, otherwise the libc (non-threaded) ones stw: with $(LIBPTHREAD) $(USE_THREADS) commented out, artsdsp netscape works, but brings up a warning dialog in netscape about the PIPE handler ;\ > rambokid: but if you prelink, your library (in that case artsdsp) gets loaded before the pthread library of the application would overdefine the symbols (as it's pre-link) > rambokid: so your preloaded part uses old symbols (or at least that is my theory whats happening) > (i.e. non-threaded or threaded, whatever your preload-library is linked to) > malte: that warning is harmless, basically, it just tells you that libmcop is trying to redefine the SIGPIPE handler, and netscape already had one stw: so let's have artsdsp-st and artsdsp-mt and a script, artsdsp which checks with ldd if the app to be run links pthread and selects the correct module? and if the command... ...is not a binary (ldd fails), well, default to something? > malte: ... default to threaded - thats normally safe (i.e. you can make a non-threaded app threaded by linking it to libpthread without breaking it usually) > malte: there are just a few cases where this doesn't work - like netscape good. would fail for netscape though... :( > malte: with a wrapper script for instance (like under debian) > malte: what would be an alternative would be a wisdom file which knows about certain apps i've never seen any distro without a netscape wrapper.....sure, roothat and mandrunk have 'em too > malte: it could also know that you better start quake with -m yeah... > malte: so did you have any "success" with netscape doing something more useful, like producing sound, or does it only "not crash" works i.e. flash produces sound why is -m optional actually? > malte: over artsd? yes, playing with xmms (and arts plugin) at the same time > malte: because it does some crude hacks to provide the application with a fixed size fragment buffer even before knowing what the application really wants (because thats what quake expects) ah okay hmm, kmid fails to build :( (HEAD) *** carsten has left channel #kde-multimedia (weg bin ich) > malte: well, I have a patch for that, too (removing the lines which draw ktrianglebutton), but thats not really a "port", so I didn't commit hat #if 0'ed them for now *** Signoff: MindWar () malte: uh oh malte: I think this slow loading is entirely my fault even unloading takes a few seconds Neil: oh, i thought it's QDom... * Neil puts this in the immediate term TODO if it were QDom, unloading a large one would be quick what's the problem then? I bet this is my inefficient use of KListView or something but I'm not sure *** mvogt has left channel #kde-multimedia I have a few ideas maybe I should profile or if you could profile I'd appreciate it I don't know yet if noatun will work on my setup (HEAD) *** Signoff: Vir (Read error to Vir[pD9E3AA06.dip.t-dialin.net]: EOF from client) noatun works on HEAD here save the skin loaders that don't compile *** Linux2001 is now known as Linux2001|zzZZzz *** Signoff: Linux2001|zzZZzz (Client Exiting) *** Closing Link: stw[p3EE06587.dip.t-dialin.net] by carter.openprojects.net (Ping timeout for stw[p3EE06587.dip.t-dialin.net]) *** Connection closed from irc.kde.org: Remote end closed connection *** Connecting to port 6667 of server irc.kde.org *** Welcome to the Internet Relay Network stw (from forward.openprojects.net) *** Your host is forward.openprojects.net, running version u2.10.05.18.(ipcheck4-5) *** This server was cobbled together Sat Feb 26 2000 at 10: 36:37 PST *** umodes available dioswkfcg, channel modes available biklmnopstv *** There are 1715 victims and 1812 hiding on 24 servers *** There are 22 operators online *** 2 unknown connection(s) *** 1323 channels have been formed *** This server has 927 clients and 1 servers connected *** Highest connection count: 950 (949 clients) *** - forward.openprojects.net Message of the Day - *** - 22/4/2001 3:26 *** - *** - Welcome to forward.openprojects.net, an IRC server for Open Projects *** - Network, located in North Palm Beach, Florida, USA. Forward is one *** - hop off of MCI's network, two from the OC-12 backbone, connected via *** - a T1 to Ft. Lauderale, FL. Thanks to Flood at Evolution *** - Communications for his sponsorship of this server! *** - *** - Open Projects Net is a special-purpose network, not a general chat *** - facility or forum. It exists to provide facilities to free *** - software and open source projects and support groups and to *** - encourage an environment in which community members can improve *** - their communication and coordination skills for the betterment of *** - all and in the public good. *** - *** - Illegal activities, warez, porn, noticeably heavy mp3 trading, *** - hax0r activity and various types of antisocial behavior are all *** - off-topic on Open Projects Net and may result in your being barred *** - from access. Please respect our rules. Thanks. *** - *** - FORWARD, DR. ROBERT L. (1932-) A consulting scientist, writer and *** - futurist, Dr. Forward has contributed written various hard science *** - fiction novels which emphasize exotic physical phenomena and *** - advanced space propulsion concepts. He has a Ph.D. in gravitational *** - physics from the University of Maryland. His master's thesis *** - involved building and operating the world's first bar antenna to *** - detect gravitational radiation. That antenna is now on exhibit at *** - the Smithsonian museum. *** - *** - For information about Open Projects Net, please check out our *** - website (http://openprojects.net/). If you'd like to contribute *** - to the OPN Fund to help with our expansion, please take a look at *** - the site (http://openprojects.net/fund_contributions.shtml). Thanks! *** - *** Welcome to Open Projects! You are on 1 ca 1(2) ft 14(14). *** Mode change "+f" for user stw by stw *** stw (stefan@p3EE06587.dip.t-dialin.net) has joined channel #kde-multimedia *** Topic for #kde-multimedia: http://space.twc.de/~stefan/kde30.html <----- LOOK HERE *** #kde-multimedia Neil 999630369 -NickServ- This nickname is registered and protected. If it is your -NickServ- nick, type /msg NickServ IDENTIFY password. Otherwise, -NickServ- please choose a different nick. *** #kde-multimedia 999612509 -NickServ- Password accepted - you are now recognized. #openproje jeff H jeff@aporia.lorn.org (Jeff) #umbclinux spambot_ H jeff@209.150.104.78 (MAKE MONEY FAST!) #SCLUG Jefe H jeff@dsl081-089-094.lax1.dsl.speakeasy.net (jeff) #freeside rluser H jeff@216.196.53.234 (Jeff Finucane) #SCLUG JefeWORK H jeff@208.48.147.204 (jeff)