Re: Please Improve Debian for Multimedia Production
Kushal Koolwal wrote: About 6 months back I had done some extensive benchmarking on real-time kernels applying RT patch to Debian stock kernel on x86 architecture. I read about call for help in maintaining,testing debian rt kernel here: http://marc.info/?l=linux-rt-usersm=123808104027590w=2 I will be glad to offer help in testing real-time kernels. I only have x86 machines. Please note I am not a DD. Kushal Koolwal Thanks for your offer! How experienced are you? Cause I think we're searching for some project leaders. Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Wed, Mar 25, 2009 at 09:05:32PM +0100, Grammostola Rosea wrote: The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production Not really. I absolutely have no problems with CONFIG_PREEMPT, dynticks, ondemand scheduler and all this fancy stuff in a vanilla 2.6.29 running on a dualcore amd64 laptop. It's an outdated myth that you need RT kernels for audio production, though it helps with very low latencies. (let's say buffer sizes below 10ms and high CPU loads) Nevertheless, for those with highest constraints or older hardware, a RT kernel is beneficial. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Hi 2009/3/26 Adrian Knoth a...@drcomp.erfurt.thur.de On Wed, Mar 25, 2009 at 09:05:32PM +0100, Grammostola Rosea wrote: The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production Not really. I absolutely have no problems with CONFIG_PREEMPT, dynticks, ondemand scheduler and all this fancy stuff in a vanilla 2.6.29 running on a dualcore amd64 laptop. It's an outdated myth that you need RT kernels for audio production, though it helps with very low latencies. (let's say buffer sizes below 10ms and high CPU loads) maybe it is worthwhile to clarify where audio production begins and audio fun ends. Recording 16 tracks + monitoring could be an impossible task with your !=RT kernel. Nevertheless, for those with highest constraints or older hardware, a RT kernel is beneficial. HTH r
Re: Please Improve Debian for Multimedia Production
I'm trying to follow this thread, but I'm not sure everybody here even using the same terminology. On Thu, Mar 26, 2009 at 02:01:22PM +0100, Cassiel wrote: Hi 2009/3/26 Adrian Knoth a...@drcomp.erfurt.thur.de On Wed, Mar 25, 2009 at 09:05:32PM +0100, Grammostola Rosea wrote: The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production Not really. I absolutely have no problems with CONFIG_PREEMPT, dynticks, ondemand scheduler and all this fancy stuff in a vanilla 2.6.29 running on a dualcore amd64 laptop. It's an outdated myth that you need RT kernels for audio production, though it helps with very low latencies. (let's say buffer sizes below 10ms and high CPU loads) maybe it is worthwhile to clarify where audio production begins and audio fun ends. Recording 16 tracks + monitoring could be an impossible task with your !=RT kernel. Could you please be more specific? What extra patches do you think need applying? What changes to the configuration are needed? Vs. what upstream kernel version? References, supporting benchmarks and such would be an added bonus. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
2009/3/26 Tzafrir Cohen tzaf...@cohens.org.il I'm trying to follow this thread, but I'm not sure everybody here even using the same terminology. On Thu, Mar 26, 2009 at 02:01:22PM +0100, Cassiel wrote: Hi 2009/3/26 Adrian Knoth a...@drcomp.erfurt.thur.de On Wed, Mar 25, 2009 at 09:05:32PM +0100, Grammostola Rosea wrote: The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production Not really. I absolutely have no problems with CONFIG_PREEMPT, dynticks, ondemand scheduler and all this fancy stuff in a vanilla 2.6.29 running on a dualcore amd64 laptop. It's an outdated myth that you need RT kernels for audio production, though it helps with very low latencies. (let's say buffer sizes below 10ms and high CPU loads) maybe it is worthwhile to clarify where audio production begins and audio fun ends. Recording 16 tracks + monitoring could be an impossible task with your !=RT kernel. Could you please be more specific? What extra patches do you think need applying? What changes to the configuration are needed? Vs. what upstream kernel version? References, supporting benchmarks and such would be an added bonus. When talking about RT kernel only one patch comes into play -- http://www.kernel.org/pub/linux/kernel/projects/rt/ other references regarding kernel config are found in -- http://www.alsa-project.org/main/index.php/Low_latency_howto IMHO, the upstream kernel version should follow the RT patch releases. Benchmarks can be easily provided by users if encouraged to use the same toolbox, eg.-- http://git.kernel.org/?p=linux/kernel/git/tglx/rt-tests.git;a=summary Actually I have none but as I introduced in the previous post recording one more track on my i386 PentiumIV dual core running Ardour with 14-16 tracks + fx + software monitoring (i.e. ardour) is possible running RT kernels, running stock kernels results in too many xruns. regards apologize for my bad english r
Re: Please Improve Debian for Multimedia Production
Cassiel wrote: 2009/3/26 Tzafrir Cohen tzaf...@cohens.org.il mailto:tzaf...@cohens.org.il I'm trying to follow this thread, but I'm not sure everybody here even using the same terminology. On Thu, Mar 26, 2009 at 02:01:22PM +0100, Cassiel wrote: Hi 2009/3/26 Adrian Knoth a...@drcomp.erfurt.thur.de mailto:a...@drcomp.erfurt.thur.de On Wed, Mar 25, 2009 at 09:05:32PM +0100, Grammostola Rosea wrote: The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production Not really. I absolutely have no problems with CONFIG_PREEMPT, dynticks, ondemand scheduler and all this fancy stuff in a vanilla 2.6.29 running on a dualcore amd64 laptop. It's an outdated myth that you need RT kernels for audio production, though it helps with very low latencies. (let's say buffer sizes below 10ms and high CPU loads) maybe it is worthwhile to clarify where audio production begins and audio fun ends. Recording 16 tracks + monitoring could be an impossible task with your !=RT kernel. Could you please be more specific? What extra patches do you think need applying? What changes to the configuration are needed? Vs. what upstream kernel version? References, supporting benchmarks and such would be an added bonus. When talking about RT kernel only one patch comes into play -- http://www.kernel.org/pub/linux/kernel/projects/rt/ other references regarding kernel config are found in -- http://www.alsa-project.org/main/index.php/Low_latency_howto IMHO, the upstream kernel version should follow the RT patch releases. That would be a nice thing imho, yes. Benchmarks can be easily provided by users if encouraged to use the same toolbox, eg.-- http://git.kernel.org/?p=linux/kernel/git/tglx/rt-tests.git;a=summary Actually I have none but as I introduced in the previous post recording one more track on my i386 PentiumIV dual core running Ardour with 14-16 tracks + fx + software monitoring (i.e. ardour) is possible running RT kernels, running stock kernels results in too many xruns. Much info about RT kernels you find here: http://rt.wiki.kernel.org/index.php/Main_Page -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Thu, Mar 26, 2009 at 03:08:07PM +0100, Cassiel wrote: When talking about RT kernel only one patch comes into play -- http://www.kernel.org/pub/linux/kernel/projects/rt/ That's a huge patch. Any idea how much effort would it take to integrae it into the existing Debian linux-2.6 package? other references regarding kernel config are found in -- http://www.alsa-project.org/main/index.php/Low_latency_howto Seems a bit dated. E.g. HPET is now enabled by default in Lenny. IMHO, the upstream kernel version should follow the RT patch releases. Benchmarks can be easily provided by users if encouraged to use the same toolbox, eg.-- http://git.kernel.org/?p=linux/kernel/git/tglx/rt-tests.git;a=summary Actually I have none but as I introduced in the previous post recording one more track on my i386 PentiumIV dual core running Ardour with 14-16 tracks + fx + software monitoring (i.e. ardour) is possible running RT kernels, running stock kernels results in too many xruns. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best ICQ# 16849754 || friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
2009/3/26 Tzafrir Cohen tzaf...@cohens.org.il On Thu, Mar 26, 2009 at 03:08:07PM +0100, Cassiel wrote: When talking about RT kernel only one patch comes into play -- http://www.kernel.org/pub/linux/kernel/projects/rt/ That's a huge patch. Any idea how much effort would it take to integrae it into the existing Debian linux-2.6 package? I really can not figure out. I am a statistician with web developing and database skills and not a C programmer, I can help in testing and building debian packages, assuming someone else takes care of integrating the patch... other references regarding kernel config are found in -- http://www.alsa-project.org/main/index.php/Low_latency_howto Seems a bit dated. E.g. HPET is now enabled by default in Lenny. Yes it is, but I found it useful as a starting point, fundamental steps are all there. IMHO, the upstream kernel version should follow the RT patch releases. Benchmarks can be easily provided by users if encouraged to use the same toolbox, eg.-- http://git.kernel.org/?p=linux/kernel/git/tglx/rt-tests.git;a=summary Actually I have none but as I introduced in the previous post recording one more track on my i386 PentiumIV dual core running Ardour with 14-16 tracks + fx + software monitoring (i.e. ardour) is possible running RT kernels, running stock kernels results in too many xruns. r
Re: Please Improve Debian for Multimedia Production
On Thu, 26 Mar 2009, Tzafrir Cohen wrote: Any idea how much effort would it take to integrae it into the existing Debian linux-2.6 package? Zero chance. The RT kernel is no plaything. The RT changes are being slowly fed to the mainline Linux kernel, but due to the complexity, it is an ongoing slow effort. So, it really would boil down to adding a new kernel flavour for Debian, probably with a lot less variants than the standard kernel (e.g. -rt doesn't make much sense for servers, Xen, etc. at this time). I.e. you would use linux-2.6-rt, or something like that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Henrique de Moraes Holschuh wrote: On Thu, 26 Mar 2009, Tzafrir Cohen wrote: Any idea how much effort would it take to integrae it into the existing Debian linux-2.6 package? Zero chance. The RT kernel is no plaything. The RT changes are being slowly fed to the mainline Linux kernel, but due to the complexity, it is an ongoing slow effort. So, it really would boil down to adding a new kernel flavour for Debian, probably with a lot less variants than the standard kernel (e.g. -rt doesn't make much sense for servers, Xen, etc. at this time). I.e. you would use linux-2.6-rt, or something like that. and IMHO only in few architectures. Which one are used for multimedia production? Which one should we support? ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
2009/3/26 Giacomo A. Catenazzi c...@debian.org Henrique de Moraes Holschuh wrote: On Thu, 26 Mar 2009, Tzafrir Cohen wrote: Any idea how much effort would it take to integrae it into the existing Debian linux-2.6 package? Zero chance. The RT kernel is no plaything. The RT changes are being slowly fed to the mainline Linux kernel, but due to the complexity, it is an ongoing slow effort. So, it really would boil down to adding a new kernel flavour for Debian, probably with a lot less variants than the standard kernel (e.g. -rt doesn't make much sense for servers, Xen, etc. at this time). I.e. you would use linux-2.6-rt, or something like that. and IMHO only in few architectures. Which one are used for multimedia production? Which one should we support? ciao cate i386, amd64, ppc I don't believe users interested in audio production are interested in other than this.. r
RE: Please Improve Debian for Multimedia Production
About 6 months back I had done some extensive benchmarking on real-time kernels applying RT patch to Debian stock kernel on x86 architecture. I read about call for help in maintaining,testing debian rt kernel here: http://marc.info/?l=linux-rt-usersm=123808104027590w=2 I will be glad to offer help in testing real-time kernels. I only have x86 machines. Please note I am not a DD. Kushal Koolwal I do blog at http://blogs.koolwal.net/ _ Internet Explorer 8 – Get your Hotmail Accelerated. Download free! http://clk.atdmt.com/MRT/go/141323790/direct/01/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Andreas Tille wrote: After reading the documentation, I still don't know if a blend is useful for us. Blends seem to be some kind of cooler tasks, is that true? Well, the terminology was taken over from tasksel at some former point in time - but it is a little bit more. Could you elaborate a bit? From what I gather (after reading the docs and skipping through the pages you have referenced), all I see are tasks (enhanced with metapackages with Recommends), and a nice web frontend. I'm pretty sure I'm missing something here. For them to be really useful there should be clearly defined use cases that justify creating the metapackages and tasks, for which I'm afraid there aren't in the multimedia world. Other than ardour or audacity, every multimedia user will probably use a different set of tools for doing their work (ie, there are lots of alternative software synthesizers/effects processors/whatever). If there is no such clear set of tools, is there a point in creating a blend? I'm not sure whether your point of view is based on your large amount of knowledge you might have about this field. You definitely know what to use and where to look at. Assume a person who is installing Debian the first time. Which advise would you give if this person might ask you: What Multimedia software is inside Debian. What should I install for a start. Which applications should I try to find out which might fit my needs best? If a person asked me that giving me the freedom to choose OS, I would be at a loss. For example, if somebody asked me: What should I install to get started in sound synthesis? (A more concrete example, and which I know best) I would not know what to say. There are big graphical sequencer and synth, like lmms, or graphical synths like puredata, or text synths, like csound or supercollider. Which one would be best? Install all of them? IME, people learn a program/language and stick to it. It's like trying to create a Software Development blend... it's just too broad and defined by personal preference, with no clear better packages. I can not imagine that multimedia is that different from other Blends. Look at the Debian Med biology task: There are more than 60 Dependencies inside Debian and there is not a single user who is using them all. We sometimes consider to split this up to some extend but did not until now. The fact is if a biologists asks you: What biological software is inside Debian? You can simply answer: Lock here: http://debian-med.alioth.debian.org/tasks/bio.html What should I install to get ready for work quickly? apt-get install med-bio For sure this installs several applications which are not needed by every person - but this is no exception to any other method to install a group of software. Metapackages are builded that way that you can deinstall every application because it uses only Recommends. So the user can start, try and in case of get bored by something remove a package later. Blends are intending to give the flat package pool some user specific structure which regards the needs of a certain group of users. And you as the multimedia developers are the people who know these users and might be able to prepare the system as good as possible. I might imagine certain tasks (please be patient - it is a suggestion of a poor user regarding multimedia stuff, just correct me if I'm wrong about your purposes): sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Although I wouldn't choose those tasks[1], but lets go over them to illustrate my point. What should we put into sound-recording? All of them? The X more popular according to popcon? The ones I use? Also, use cases overlap: I don't think there is a sound recorder that is not also a sound player. Probably syncing with existing DebTags (I did not checked these) should be a good advise. Probably more fine graining needs to be done. At least I would *really* love to have an overview about these categories in Debian. Technically you might also approach this by applying DebTags and my goal is to technically merge DebTags and Blends technique stronger in the future. But as far as I know there is no such thing like a tasks or a bugs overview based on DebTags. Moreover you are able to include packages into your focus which are maintained by maintainers who are not joining your Multimedia Team (for whatever reason). I hope I was able to give some reasons why a Blend makes sense. I agree that it makes sense, at least for some users. However, maintaining a Blend is (I assume) time consuming. What I'm wondering is if it is worth the effort. Is it going to ease our work as a team? Is it going to make it easier for 64studio to integrate with us? [1] Actually, the multimedia name
why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
Hi, Now we're talking about improving Debian for multimedia, realtime kernels and the like, I thought let's make some work on more things to overcome some dissadvantages of Debian for audio production compared to other distro's. Why is such a core app and also beautiful app as Ardour is, not even in Debian stable or testing? This is a big problem imo and it should be solved as soon as possible. I can't imagine that there is a real problem, cause I know the Ardour devs as people who respect GNU/GPL... I read this on the Debian multimedia mailinglist: EDR It's not a matter of debian developer laziness ... the ardour in sid EDR needs patches to _upstream_ libraries. If/when those upstream libraries EDR accept the patches the ardour devs need, then those libraries can get EDR into debian and ardour can use the debian packaged versions rather than EDR it's own forked versions. 100% agreed, ardour not in lenny is a Real Pity (TM). To recap happened: 0) the ardour package was built against some 3rd party libs shipped inside the upstream tarball, this raised an RC bug 1) that bug was around for a long time, there were no easy fix for that, but eventually all of the patches made it the 3rd party upstream projects, which in turned made it to si 2) I've fixed RC bug in ardour in version 2.7.1-2 http://packages.debian.org/changelogs/pool/main/a/ardour/ardour_2.7.1-2/changelog It was on Dec 18th, that means nearly 2 months before lenny got release. At this point ardour was RC-free BUT.. 3) It was depending on jackd 0.109.2, uploaded a few days before. Note that jack 0.109.2 was a very important release because it fixed important bugs in version 0.106, which had been around for almost one year. Unfortunately lenny was already freezed by that time, and although both of the above updates were really safe (IMO) and despite all the efforts I and especially Reinhard put into convincing the release managers, we are unable to convince them to accept the updates in lenny. I personally felt very disappointed by all this, especially considering that lenny got out *2* months later. ( http://www.mail-archive.com/debian-multime...@lists.debian.org/msg03163.html ) Please some reactions on this issue and I hope it can be solved! Would be great! :) Thanks in advance, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
On Wed, 2009-03-25 at 12:58 +0100, Grammostola Rosea wrote: Why is such a core app and also beautiful app as Ardour is, not even in Debian stable or testing? This is a big problem imo and it should be solved as soon as possible. I can't imagine that there is a real problem, cause I know the Ardour devs as people who respect GNU/GPL... Someone needs to make it build: https://buildd.debian.org/fetch.cgi?pkg=ardour;ver=1%3A2.7.1-2;arch=s390;stamp=1229659387 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Wed, 25 Mar 2009, Felipe Sateler wrote: Could you elaborate a bit? From what I gather (after reading the docs and skipping through the pages you have referenced), all I see are tasks (enhanced with metapackages with Recommends), and a nice web frontend. I'm pretty sure I'm missing something here. Perhaps some clarification is done below - if not, just ask again. If a person asked me that giving me the freedom to choose OS, I would be at a loss. For example, if somebody asked me: What should I install to get started in sound synthesis? (A more concrete example, and which I know best) I would not know what to say. There are big graphical sequencer and synth, like lmms, or graphical synths like puredata, or text synths, like csound or supercollider. Which one would be best? Install all of them? IME, people learn a program/language and stick to it. It's like trying to create a Software Development blend... it's just too broad and defined by personal preference, with no clear better packages. I think I understood your point. But to enable people developing their own taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia menu in Debian. Well, sure the applications will be installed in the menu of your desktop if you if you installed the according package - but there is no central place to pick the packages which might be interesting. Just take me as a more or less multimedia ignorant person I would have a hard time to find out all the relevant packages for graphical sequencing so I'd be really glad if there would be a tasks page which assembles the short descriptions and links to the homepage of the projects to enable a quick overview. In how far it is different for instance to Debian Junior's puzzles page. There are a lot of nice puzzles in Debian and you will finally pick some favourites of them. So why not presenting a reasonable overview about what is there? sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? but lets go over them to illustrate my point. What should we put into sound-recording? All of them? Yes. Why not? If there are bad ones which should not be Recommended or Suggested I wonder why they should hang around in Debian at all. The X more popular according to popcon? No. Adding popcon stats to the tasks files is in the upper quarter of my todo list. People can decide themselves whether they want to try a package with low or high popcon first. The ones I use? No. This contradicts your own arguing. Also, use cases overlap: I don't think there is a sound recorder that is not also a sound player. The overlap is no problem and I explained in detail for several Blends: We do not want to build an exclusive categorisation which might be hard to understand for our users. The important thing is to support our users. A specific user wants to solve a certain task (and thus installs a certain metapackage). The question whether some Dependencies are also mentioned in a different metapackage is completely useles for this task. So in fact we do *not* build a categorisation tree but build pools of useful software for certain tasks which can definitely have overlaps. To come back to your example: A user who is seeking for his optimal sound player is not served best if we hide an application from his view by including it into sound recorders exclusively. While chances might be good that a sound recorder is not as lightweight as a pure player the user will find out this quickly if he is looking for only a lightweight player - but perhaps he becomes happy later about the added value of his favourite player if it also is able to record sound. I think I have to include this into the Blends doc somewhere ... I agree that it makes sense, at least for some users. However, maintaining a Blend is (I assume) time consuming. It depends: Look for instance at the software page of the Debian Accessibility project[1]: This page existed for a long time (BTW, with Debian Med we started with something like that as well and learned that maintaining such static pages is really hard). They were a perfect preparation to enable me to generate the tasks files in 15 minutes and some further work was done by Samuel Thibault (who is actually member of the project) which all in all did not took him much more than the same time to add some new projects. The result can be seen here in the tasks[2] and bugs[3] pages. IMHO this time is quite well spend for the result that you gain the following advantages: 1. General overview over your work 2. Translations of the descriptions of the
Re: why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
Grammostola Rosea wrote: I read this on the Debian multimedia mailinglist: Unfortunately lenny was already freezed by that time, and although both of the above updates were really safe (IMO) and despite all the efforts I and especially Reinhard put into convincing the release managers, we are unable to convince them to accept the updates in lenny. I personally felt very disappointed by all this, especially considering that lenny got out *2* months later. Please some reactions on this issue and I hope it can be solved! Would be great! :) IMHO, the best thing to do in these cases is to prepare lenny backports of the packages... It is not as good as if the packages were in lenny, but it allows lenny users to easily install the packages without switching to testing or waiting for the next release. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: why is Ardour pretty outdated in stable and not in testing? (was Re: Please Improve Debian for Multimedia Production)
2009/3/25 Julien Cristau jcris...@debian.org On Wed, 2009-03-25 at 12:58 +0100, Grammostola Rosea wrote: Why is such a core app and also beautiful app as Ardour is, not even in Debian stable or testing? This is a big problem imo and it should be solved as soon as possible. I can't imagine that there is a real problem, cause I know the Ardour devs as people who respect GNU/GPL... Someone needs to make it build: https://buildd.debian.org/fetch.cgi?pkg=ardour;ver=1%3A2.7.1-2;arch=s390;stamp=1229659387 Hi, new to the list and to the thread. I totally agree with Grammostola Rosea about the core app nature of ardour and everybody interested in multimedia production needs this pkg like a fish needs water to swim and, sooner or later, he will need a RT kernel. my dime r
Re: Please Improve Debian for Multimedia Production
taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia menu in Debian. An menu entry for multimedia sounds good to me (Ubuntu has an menu entry for 'multimedia production: - music production - video production (or something close to that). This is good imo because audio apps are a lot small apps which clutter up in the menu now. Well, sure the applications will be installed in the menu of your desktop if you if you installed the according package - but there is no central place to pick the packages which might be interesting. Just take me as a more or less multimedia ignorant person I would have a hard time to find out all the relevant packages for graphical sequencing so I'd be really glad if there would be a tasks page which assembles the short descriptions and links to the homepage of the projects to enable a quick overview. In how far it is different for instance to Debian Junior's puzzles page. There are a lot of nice puzzles in Debian and you will finally pick some favourites of them. So why not presenting a reasonable overview about what is there? sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? I think this should be possible: you just pick a few, frequently used apps (when you build an distro you also have to choose some). Just to gave an idea. The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production imo. Ubuntu Studio has also some metapackages for video, music and artwork, but they also have an realtime kernel and a tool to handle the configuration. \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Wed, 25 Mar 2009, Grammostola Rosea wrote: taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia menu in Debian. An menu entry for multimedia sounds good to me (Ubuntu has an menu entry for 'multimedia production: - music production - video production (or something close to that). This is good imo because audio apps are a lot small apps which clutter up in the menu now. Nothing against this but I used the term menu in a different than this technical meaning. I hope this became clear in my mail. Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? I think this should be possible: you just pick a few, frequently used apps (when you build an distro you also have to choose some). Just to gave an idea. But we do not choose a distro - we just have a distro which is called Debian. And we want to handle the packages which are just inside Debian. The choice inside Debian was done based on the user interest and time of developers. The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production imo. Ubuntu Studio has also some metapackages for video, music and artwork, but they also have an realtime kernel and a tool to handle the configuration. Well, I think the problem with the RT kernel was understood and it is just a an issue of just *doing* the actual packaging - so why not just starting with this? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Andreas Tille wrote: On Wed, 25 Mar 2009, Grammostola Rosea wrote: taste they need to be informed what to choose from. It's like a restaurant where you choose from a menu. Currently we are lacking a complete multimedia menu in Debian. An menu entry for multimedia sounds good to me (Ubuntu has an menu entry for 'multimedia production: - music production - video production (or something close to that). This is good imo because audio apps are a lot small apps which clutter up in the menu now. Nothing against this but I used the term menu in a different than this technical meaning. I hope this became clear in my mail. That was clear, but it bumped up a old idea I had in my head ;) Please take that idea serious... Although I wouldn't choose those tasks[1], Sure - I told you I'm uneducated about your work - one reason more for you to make the tasks better, right? I think this should be possible: you just pick a few, frequently used apps (when you build an distro you also have to choose some). Just to gave an idea. But we do not choose a distro - we just have a distro which is called Debian. And we want to handle the packages which are just inside Debian. The choice inside Debian was done based on the user interest and time of developers. Now you misunderstood what I said ;) Maybe I was not clear, but the discussion was about which apps you should choose for such a metapackage, and I said, just pick some common used apps, to give an idea what is possible. The problem is an realtime kernel and a proper configuration for music production. Without that, you better stay away from music production imo. Ubuntu Studio has also some metapackages for video, music and artwork, but they also have an realtime kernel and a tool to handle the configuration. Well, I think the problem with the RT kernel was understood and it is just a an issue of just *doing* the actual packaging - so why not just starting with this? [bit offtopic, there is another thread about this] I really like the openness for an RT kernel in Debian. I didn't expect it, so I'm really happy with. I hope some guys will jump in ! I will do my best to tell it around and ask people to join [/bit offtopic, there is another thread about this] Kind regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Wed, 25 Mar 2009, Grammostola Rosea wrote: Nothing against this but I used the term menu in a different than this technical meaning. I hope this became clear in my mail. That was clear, but it bumped up a old idea I had in my head ;) Please take that idea serious... To whom do you targeting this request? To me? - Probably not, because I will not fiddle around with those menus. The best idea would be if *you* take your suggestion serious and file bug report against menu (including patch) or if you fix the *.desktop files of relevant applications. But if I'm not missleaded you have to foreward this proposal to freedesktop.org where the menu standard is defined. This is probably a lot of work - and proves you are taking the request serious... Now you misunderstood what I said ;) Maybe I was not clear, but the discussion was about which apps you should choose for such a metapackage, and I said, just pick some common used apps, to give an idea what is possible. Ah OK. But hey, my problem is that I do not know commonly used multimedia apps. So why not starting with my suggestion to do some brainstorming in the Wiki? Just find some categories and packages that fit into. [bit offtopic, there is another thread about this] I really like the openness for an RT kernel in Debian. I didn't expect it, so I'm really happy with. Well, finally it is Free Software (if not it would not be included), right. I hope some guys will jump in ! I learned that this strategy will not work. Pointing your finger on an open problem and then just wait if somebody else will solve it just will not work. Try to start solving the problem yourself - we will help you in case of trouble. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Andreas Tille wrote: On Sun, 22 Mar 2009, Jim wrote: Hi. I took the suggestion of one of the replies to your original post and read about debian pure blends, and at first I thought demudi was a pure blend; At the time of writing the DeMuDi project *intended* to become 100% Debian - but this intend was not fullfilled finally. The DeMuDi project is dead AFAIK. The 64studio spawned from it, and can't be a pure blend. Actually the demudi team merged with the Debian Multimedia Maintainers, so we now work together. I would suggest removing it from the blends list (although the section on why demudi/64studio couldn't be a blend is useful to highlight that blends are _in_ Debian). it's listed as one of the projects but is not actually a pure blend, which I guess means they might have updated apps and specifically compiled kernels to support various pro audio needs. Yes, DeMuDi does not fall under the definition of a Blend. But this is no reason not to start a new effort inside Debian to support multimedia. There is an effort to support multimedia, a merge of the 2 previous efforts. After reading the documentation, I still don't know if a blend is useful for us. Blends seem to be some kind of cooler tasks, is that true? For them to be really useful there should be clearly defined use cases that justify creating the metapackages and tasks, for which I'm afraid there aren't in the multimedia world. Other than ardour or audacity, every multimedia user will probably use a different set of tools for doing their work (ie, there are lots of alternative software synthesizers/effects processors/whatever). If there is no such clear set of tools, is there a point in creating a blend? -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Mon, 23 Mar 2009, Felipe Sateler wrote: The DeMuDi project is dead AFAIK. This fits to my observation. The 64studio spawned from it, and can't be a pure blend. Actually the demudi team merged with the Debian Multimedia Maintainers, so we now work together. That's really good. I would suggest removing it from the blends list (although the section on why demudi/64studio couldn't be a blend is useful to highlight that blends are _in_ Debian). I'd suggest to keep it for some while there for the purpose you mentioned except if there is some new effort taking over the role of a Blend (see below). There is an effort to support multimedia, a merge of the 2 previous efforts. This is really godd news and gives some hope. After reading the documentation, I still don't know if a blend is useful for us. Blends seem to be some kind of cooler tasks, is that true? Well, the terminology was taken over from tasksel at some former point in time - but it is a little bit more. For them to be really useful there should be clearly defined use cases that justify creating the metapackages and tasks, for which I'm afraid there aren't in the multimedia world. Other than ardour or audacity, every multimedia user will probably use a different set of tools for doing their work (ie, there are lots of alternative software synthesizers/effects processors/whatever). If there is no such clear set of tools, is there a point in creating a blend? I'm not sure whether your point of view is based on your large amount of knowledge you might have about this field. You definitely know what to use and where to look at. Assume a person who is installing Debian the first time. Which advise would you give if this person might ask you: What Multimedia software is inside Debian. What should I install for a start. Which applications should I try to find out which might fit my needs best? I can not imagine that multimedia is that different from other Blends. Look at the Debian Med biology task: There are more than 60 Dependencies inside Debian and there is not a single user who is using them all. We sometimes consider to split this up to some extend but did not until now. The fact is if a biologists asks you: What biological software is inside Debian? You can simply answer: Lock here: http://debian-med.alioth.debian.org/tasks/bio.html What should I install to get ready for work quickly? apt-get install med-bio For sure this installs several applications which are not needed by every person - but this is no exception to any other method to install a group of software. Metapackages are builded that way that you can deinstall every application because it uses only Recommends. So the user can start, try and in case of get bored by something remove a package later. Blends are intending to give the flat package pool some user specific structure which regards the needs of a certain group of users. And you as the multimedia developers are the people who know these users and might be able to prepare the system as good as possible. I might imagine certain tasks (please be patient - it is a suggestion of a poor user regarding multimedia stuff, just correct me if I'm wrong about your purposes): sound-recording sound-playing video-recording video-playing image-editors image-viewers note-editors (for noteedit - no idea whether this is a reasonable category name) ... Probably syncing with existing DebTags (I did not checked these) should be a good advise. Probably more fine graining needs to be done. At least I would *really* love to have an overview about these categories in Debian. Technically you might also approach this by applying DebTags and my goal is to technically merge DebTags and Blends technique stronger in the future. But as far as I know there is no such thing like a tasks or a bugs overview based on DebTags. Moreover you are able to include packages into your focus which are maintained by maintainers who are not joining your Multimedia Team (for whatever reason). I hope I was able to give some reasons why a Blend makes sense. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Grammostola Rosea, Hi. I took the suggestion of one of the replies to your original post and read about debian pure blends, and at first I thought demudi was a pure blend; it's listed as one of the projects but is not actually a pure blend, which I guess means they might have updated apps and specifically compiled kernels to support various pro audio needs. I want also to direct your attention to the kernel, as it has the possibility to be more supportive of those specific needs, by having low latency and real-time extensions patched and enabled. The debian folks (especially waldi aka Bastien Blank will say some or all of these are less stable than they could be -- perhaps googling around or asking him when he's not so busy will drum up some details.) To the group, I'd like to see Demudi become a pure blend. What are the issues? On Fri, Mar 20, 2009 at 7:02 AM, Grammostola Rosea rosea.grammost...@gmail.com wrote: Hi, Since a while I'm pretty active in using Debian/Linux for Multimedia production, especially focusing on music production (check www.linuxmusicians.com for instance). Debian is a great system to use for this. Unfortunately there are nice music production applications which are not in Debian yet or are pretty outdated (also those in unstable). It would be nice if we could improve Debian for multimedia production and package more multimedia packages and keep them up to date. For instance, I posted some apps which are not in Debian right now as wishes (RFP): http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=rosea.grammost...@gmail.com (There is work on progress on Frescobaldi, Rumor (my first Debian package ;) ) and Gtklick.) Of course we have the Debian Multimedia Team, which takes care of a lot of multimedia packages for Debian. So if you like to help in this progress, the best thing you could do imo is joining the Debian Multimedia Team: http://wiki.debian.org/DebianMultimedia http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers Thanks in advance, \r ps: I'm not an official member of the Debian Multimedia Team myself. I'm just a musician which uses Debian now, but I think I'm gonna join the team myself. I recently build my first Debian package :), so I'm almost ready to join ;) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Sun, 22 Mar 2009, Jim wrote: Hi. I took the suggestion of one of the replies to your original post and read about debian pure blends, and at first I thought demudi was a pure blend; At the time of writing the DeMuDi project *intended* to become 100% Debian - but this intend was not fullfilled finally. it's listed as one of the projects but is not actually a pure blend, which I guess means they might have updated apps and specifically compiled kernels to support various pro audio needs. Yes, DeMuDi does not fall under the definition of a Blend. But this is no reason not to start a new effort inside Debian to support multimedia. I'd like to see Demudi become a pure blend. What are the issues? If you ask me - just go for it. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
Michael Hanke wrote: Hi, On Fri, Mar 20, 2009 at 04:29:35PM +0100, Fabian Greffrath wrote: As an additional hint the multimedia team might consider using the Debian Pure Blends framework which enables them to show quite simply what is just there and what they are working on (for instance see just issued bits [1]). So if you are interested in those tasks and bugs pages or in multimedia related metapackages just ask me in case there might be some technical questions about Blends. You can read more here [2]. Speaking for the pkg-multimedia-maintainers, i.e. the actual Debian Multimedia Team, we don't see ourself as a Debian Blend. We are just a bunch of maintainers maintaining a bunch of packages *in* Debian: Right, and that is what blends are about -- maintaining packages *in* Debian. You just get some additional magic that helps you to make your work a bit more visible and guides users like the starter of this thread, as well as potential contributers My aim as the thread starter was to ask for developers and/or package maintainers for multimedia in Debian. Because there are a lot nice packages which are not in Debian now or are pretty outdated. I know the Debian Multimedia Team exist, but I think they can use some help here... Regards, \r -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Sat, 21 Mar 2009, Grammostola Rosea wrote: Speaking for the pkg-multimedia-maintainers, i.e. the actual Debian Multimedia Team, we don't see ourself as a Debian Blend. We are just a bunch of maintainers maintaining a bunch of packages *in* Debian: Right, and that is what blends are about -- maintaining packages *in* Debian. I really hope that people will get the right impression what Blends are and start reading before they make wrong assumptions. My aim as the thread starter was to ask for developers and/or package maintainers for multimedia in Debian. Because there are a lot nice packages which are not in Debian now or are pretty outdated. I know the Debian Multimedia Team exist, but I think they can use some help here... Yes, definitely. And to get some help you need to be visible and give your project some better structure. If you want to learn about the reason for maintaining a Blend instead of beeing a bunch of maintainers just read the doc [1] (BTW, this helps to avoid wrong asumptions that packages are not *in* Debian). Kind regards Andreas. [1] http://blends.alioth.debian.org/blends/ -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please Improve Debian for Multimedia Production
On Fri, 20 Mar 2009, Grammostola Rosea wrote: For instance, I posted some apps which are not in Debian right now as wishes (RFP): http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=rosea.grammost...@gmail.com (There is work on progress on Frescobaldi, Rumor (my first Debian package ;) ) and Gtklick.) Of course we have the Debian Multimedia Team, which takes care of a lot of multimedia packages for Debian. So if you like to help in this progress, the best thing you could do imo is joining the Debian Multimedia Team: http://wiki.debian.org/DebianMultimedia http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers As an additional hint the multimedia team might consider using the Debian Pure Blends framework which enables them to show quite simply what is just there and what they are working on (for instance see just issued bits [1]). So if you are interested in those tasks and bugs pages or in multimedia related metapackages just ask me in case there might be some technical questions about Blends. You can read more here [2]. ps: I'm not an official member of the Debian Multimedia Team myself. I'm just a musician which uses Debian now, but I think I'm gonna join the team myself. I recently build my first Debian package :), so I'm almost ready to join ;) Good luck for joining Andreas. [1] http://lists.debian.org/debian-devel-announce/2009/03/msg00013.html [2] http://blends.alioth.debian.org/blends/ -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: Please Improve Debian for Multimedia Production
As an additional hint the multimedia team might consider using the Debian Pure Blends framework which enables them to show quite simply what is just there and what they are working on (for instance see just issued bits [1]). So if you are interested in those tasks and bugs pages or in multimedia related metapackages just ask me in case there might be some technical questions about Blends. You can read more here [2]. Speaking for the pkg-multimedia-maintainers, i.e. the actual Debian Multimedia Team, we don't see ourself as a Debian Blend. We are just a bunch of maintainers maintaining a bunch of packages *in* Debian: http://qa.debian.org/developer.php?login=pkg-multimedia-maintainers%40lists.alioth.debian.org Have a nice weekend, Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: Please Improve Debian for Multimedia Production
Hi, On Fri, Mar 20, 2009 at 04:29:35PM +0100, Fabian Greffrath wrote: As an additional hint the multimedia team might consider using the Debian Pure Blends framework which enables them to show quite simply what is just there and what they are working on (for instance see just issued bits [1]). So if you are interested in those tasks and bugs pages or in multimedia related metapackages just ask me in case there might be some technical questions about Blends. You can read more here [2]. Speaking for the pkg-multimedia-maintainers, i.e. the actual Debian Multimedia Team, we don't see ourself as a Debian Blend. We are just a bunch of maintainers maintaining a bunch of packages *in* Debian: Right, and that is what blends are about -- maintaining packages *in* Debian. You just get some additional magic that helps you to make your work a bit more visible and guides users like the starter of this thread, as well as potential contributers Overly simplifying, you get something like this: http://debian-med.alioth.debian.org/tasks/imaging.html instead of: http://qa.debian.org/developer.php?login=pkg-multimedia-maintainers%40lists.alioth.debian.org ;-) Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
