Slashdot Mirror

It was good to see Dave Phillips being quoted here, since he's probably the most well-informed source on this subject, and, since Dave himself is an active developer of any projects, a fairly independent and honest source at that. Its a bit depressing to see so many comments thus far show little knowledge of whats actually going on in the Linux audio/MIDI/music development community. First off all, as the article mentioned, we do now have support for high end ("professional") interfaces, including the amazing RME Hammerfall and devices built around the ICE1712 chip such as the Delta101 from Midiman. The Hammerfall is a potentially revolutionary card, bringing 26 input channels and 26 output channels into your system for around $500. Its all digital, and so all the stuff mentioned here about RF noise is null and void. Secondly, from a technical standpoint, Linux is a much better platform for multimedia than almost any other operating system, including BeOS. With Ingo Molnar's low latency patches for the 2.2 kernels, and almost without patches in the 2.3 series, Linux can support sustained, essentially guaranteed sub-5msec latency regardless of system load. This is truly impressive. Its too bad that Linus doesn't seem to care too much about this, but plenty of others do. In addition to this almost-dedicated-h/w level of performance, we can provide high performance, stable, reliable libraries for networking, database operations, multi user facilities, high end graphics cards, and big disk arrays. Finally, companies like Dell, Compaq and Gateway now sell Linux preinstalled. One might have hoped that such a platform would have companies like Steinberg running to us, but alas, not yet. That said, we *are* talking to Steinberg, and they are considering the possibility of an open source implementation (probably not by them) of a VST host. This would be an exciting development. VST (1 or 2) is not by any means a particularly superb specification for a plugin API from a technical point of view, but its widespread support by the industry makes it important. Since we in the Linux world tend to prefer technically superior solutions to mere marketing strategies, there is also work going on a mailing list that any developers reading this should know about: the linux-audio-dev list (send a message containing "subscribe linux-audio-dev" to majordomo@ginette.musique.umontreal.ca . On that list, we have been discussing two related API's, one called LADSPA (the Linux-Audi-Dev Simple Plugin API) and one called MuCoS (not its final name, we hope). LADPSA is intended as an initial plugin API standard that offers about the same functionality as VST1.0 (and indeed, could be used to support VST1.0). MuCoS is a much more advanced system designed to support sample accurate, low latency, high performance plugins. LADSPA is getting close to a final definition. There are also people (I am one of them) who *are* working with musicians to make sure that we are developing pro-quality, studio-ready tools rather than bedroom toys. I am actively engaged in writing multichannel recording software designed to replace racks of Alesis M20 ADAT recorders, for example, and work with a commercial pro studio to make sure that what I'm doing works in a real studio setting. However, this is not simple work. When your goals are to do things at least as well as ProTools, a program under development for at least 5 or 6 years, and used by most major studios, its not a matter of a long weekend hacking late into the night. There are many careful and tricky design questions to be answered. The solutions are not the same for all categories of programs (e.g. HDR systems place a different kind of stress on a system than synthesizers/trackers do). Its slow hard work, quite different from web programming, database work or kernel hacking because of the real-time nature of the task. So yeah, we're getting there, and nobody that I know on linux-audio-dev is under illusion that we've written ProTools yet. But there is no single "killer app" for audio/music/MIDI work, just a series of tools that all need to be developed. That said, there is way too much duplication of effort. I'm all for the GNOME/KDE split, because I think that having multiple strands of development/experimentation is a good thing. But given that we don't have a single soundfile editor capable of doing a lot of what even the most rudimentary commercial Windows/Mac apps can do, let alone handle a 24 track 24/48 recording, it seems crazy to me that we have at least a half dozen projects working on "the GIMP for audio". The comparison seems like a good one to me, because I recently read about issues that the GIMP has with CMYK color, a required feature for professional printing purposes. Its a good analogy with many Linux soundfile editing programs, which are slowly adding plugin architectures, neat FX etc. but are (mostly) fundamentally written around a stereo assumption - completely inadequate for studio work. OK, I've written enough here. Come join us on linux-audio-dev if you're serious about Linux and audio.

4) A question about Mandrake... by Mr. Penguin

As we all know, at first Mandrake was little more than a repackaged version of Red Hat. That's changed a bit with the newer versions. My question is this: to what degree will Mandrake continue to differ from RedHat and will there ever be a "developer" version (i.e. one that is centered towards those who are a bit more technically competant)?

If you want the whole 2.1 MB html file, I posted it on my server

1. If you haven't previously contributed to an open source project, contribute something.
   
   • Write a brief HOWTO.
   • Translate the messages for your favorite program into your language if it hasn't been done already.
   • Post that Emacs Lisp package you've been playing with on your own machine.
2. Get the official release of Windows 2000 and review it against the most recent version of your favorite Linux distribution.
3. Benchmark the performance of some aspect of Windows 2000, or the software under it, against comparable free software. If you are doing it straight out of the box because you don't know how to tweek one or the other, say so. That's a valid comparison too.
4. Give a Linux or FreeBSD CD to a friend who has asked you about it. Help him install it.
5. Donate a book about some major piece of free software, or even The Cathedral and the Bazaar to your library.
6. Donate Linux or FreeBSD CDs to your library.
7. Spend a couple hours in the Linux newsgroups sending helpful answers to newbies.

• Linux Internationalisation Initiative
• Linux i18n Project, which is at least loosely affiliated with Mandrake since one of their employees is the contact for the project
• Free Mulitilingual Platforms
• Gnome and KDE have also both been actively pursuing internationalization

It would be even better to port the Indians to English.

Yes, I know this was a joke. I did laugh. But I wanted to raise a point that isn't always obvious to monolingual English speakers.

I'm the team leader for the Esperanto Translation Team for the Free Translation Project. Esperanto is unusual among languages. To the best of my knowledge, there is not a single monolingual Esperantist anywhere in the world, nor is there likely to be one any time soon. We have no native country as a language and aren't seeking one. For anyone who is confused by this, Esperanto is an artificial language created in 1887. It is usually learned as a second, third or subsequent language.

Everyone on the Esperanto Translation Team could be using free software under other languages for which the localization has already been done. I use Linux with English literals except when I an validating translations. But there is a reason to have complete locales for any language that users might want to use software in conjunction with. I can read English just fine, but when I want to write to a non-English-speaking friend in Esperanto, I need an e-mail client that can handle the character set. And when I am writing in Esperanto, it takes me a moment to switch back and forth. I don't do it instantly. Having messages, menus, etc., in the same language I am working in is a great help.

Teaching the entire world a single common language will not eliminate the need for computing environments that support their native languages. The only thing that would accomplish that would be if we all learned a single language and abandoned all others. That would involve abandoning names, literature, culture. It isn't a step many people are willing to take. Certainly, teach the world English, or French, German, Russian, Hindi, Chinese, Japanese, Arabic, Latin, Esperanto or any other language. Don't ask them all to give up the perfectly good languages they already have.

Yes, there is a project for localization of free software. The Free Translation Project is an ongoing project to localize free software into as many languages as possible. If yours isn't one of the one's we're already doing, there are a number of people who can mentor you in starting a translation team for your language.

This is not the only project handling translation of free software. Several of the distributions have projects going to translate their installation tools and documentation. And both Gnome and KDE have internationalization projects.

I know it's too late now, but I would like to see write in candidates as well next time. I'm more interested in hearing about who has done what for open source than I really am about who wins. Since the spaces aren't there on the forms, I'd be delighted to hear from people here about people who didn't make the list. They probably didn't have the chance for the widespread recognition necessary to win, but let's mention them publically anyway. I'll start.

I nominated François Pinard, leader of the Free Translation Project for the unsung hero award. He has managed to gather support for the project a little at a time and keep it going largely through his own effort. There are certainly plenty of translators working on many of the individual languages, but he has done the organizational work to connect software projects with translation teams. If you are competent to translate, especially into a minority language, one of the best ways I can think of to thank him is to join or form a translation team.

• 
  
• CUIs assume that the user is human
• CUI command parsers are often big and ugly to write
• CUIs tend to adopt a "big is beautiful" approach
• Programs having CUIs are hard to combine with other programs
• CUIs do not scale well
• Most important, CUIs do not take advantage of software leverage

• Any interface that I can't automate out of my way is a bad one because no matter how optimized it is, it forces a certain minimum amount of interaction with me.
• Internal protocols and file formats should be documented and accessible to readily available tools.

• If an open source project is going to thrive, it needs to interface with existing protocols and/or file formats.
• Protocols that are published for free on the Web (RFCs, etc.) are the most widely available.
• The more widely available the interfaces the greater the number of collaborators the project can potentially attract.
• The code itself publishes the interfaces in open source. Since they can't be kept completely secret, there's not much point in hiding them.
• Open interfaces encourage interfacing other projects with yours.

• The Free Translation Project, doing translation of the messages from free software into quite a few languages.
• The Linux I18N Project
• The Linux Internationalization Initiative

• The Free Translation Project, doing translation of the messages from free software into quite a few languages.
• The Linux I18N Project
• The Linux Internationalization Initiative

It seems that there may be several open source internationalization and localization projects springing up with some overlap. I won't suggest that they should necessarily merge. There a re a variety of goals and tasks here. However, anyone with interest in one of them should know about the others. Take a look at the Free Translation Project. It has been going for several years now. At the very least, I would love to see the web sites for each of the projects contain links to the others. Let's build on each other's work rather than duplicate it.

It's beeing distributed by default with many Linux distros (try man gettext) and is essentially a tool for software developers to make their software translateable. This is essentially done by storing all the program output strings in a file, making it easy for translation.

After a software package is translated into a language and sent pack to the developer, it is distributed by default with all instances of that software, and all the end user has to do is to set an environment variable (in bash export LANG=xx, where xx is the language code, like ja for japanese, sv for swedish etc.) to get all output on his system in that language, in case a translation exists.

It works very well, except from the sad fact that far from all software is translated, not to mention the documentation.

export LANG=sv_SE

in your .bashrc on your favourite Linux distro and get a lot of program output automatically translated for you (I thought your native tongue had to be Swedish, just like mine, after reading your user info ;)

Hence, in case you want your software translated, you may try to use this translation effort.

Another comment regarding this story: I know that i18n is a huge and complex process, and it has to be divided into several sub-processes and efforts, but i still hope that there won't be a lot of new other translation APIs and translation groups that won't work together in their efforts. I hope this Li18n initiative will act much like a common resource for Linux Software translation, and work with those translation efforts already existant. We don't need the translation work done twice by different groups.

Today there is already the Gnome i18n group, the KDE i18n group, the GNU/FSF translation project, the various documentation translation groups, the Mozilla i18n project, and various other groups, and although they don't work with the same translations, I wish they could work more closely together, without duplicating efforts with translation APIs, translation software, documentation for translators, etc. Just my thoughts.