From kde-multimedia Mon Feb 24 15:15:21 2003 From: Stefan Westerfeld Date: Mon, 24 Feb 2003 15:15:21 +0000 To: kde-multimedia Subject: Re: aRts vs JACK X-MARC-Message: https://marc.info/?l=kde-multimedia&m=104609989721159 Hi! On Mon, Feb 24, 2003 at 06:29:39AM -0800, Neil Stevens wrote: > On Monday February 24, 2003 05:17, Stefan Westerfeld wrote: > > Adding CSL support to KDE right now seems to me the right thing to do. > > It does not disturb people using aRts (because things will continue to > > function exactly as they do now), but it helps people not using aRts. > > And doesn't cost much to do it. > > That's fine, add CSL as an add-on. But as long as CSL is glib-tied, it's > not the answer to KDE's needs. There is still some confusion, I think. * CSL = common sound layer Is a simple plain C API. You give it an audio stream. It plays it. You ask it for an audio stream. It gives it to you. It does not have _any_ dependancies. * BSE/SFK = bedevilled sound engine / synthesis fusion kit Is an aRts-like synthesis and effects thing using glib, currently exclusively used in BEAST. I do not recommend adding it to KDE at this point in time. If MCOP/SFI can be merged at some point in time remains to be seen. This however would most certainly mean a glib dependancy for the merged result. If this is inacceptable for aRts for some reason (it may for whatever reason not be my right to decide what is right for aRts and what not, even although I have written a lot of code in aRts), then aRts will have to remain without glib dependancy, and presumably without sane C language binding. Strategically however deciding against glib for aRts in the future this means that if you're a C coder (and there are a lot of these out there), aRts will not be for you, which means loosing potential contributors/users. If you look at Arts::Thread, Arts::Dispatcher, arts/gsl/gslglib* you will see that aRts is duplicating quite some glib functionality even today. At some point however, using glib, or alternatively, using Qt might be cheaper than duplicating everything. Currently I however refuse to consider depending aRts on a GUI toolkit, whereas glib would only be a moderately sized C portability library. In fact, I would even think that depending Qt on glib would be a very wise decision interoperability wise, because it would open a much easier path towards in-process coexistence of GNOME and KDE code snippets. Cu... Stefan -- -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *- _______________________________________________ kde-multimedia mailing list kde-multimedia@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-multimedia