You obviously aren't familiar with the Augan II. Its a pro-level, $$$$ DAW built around Linux and X. See http://www.augan.com/ There are lots of other reasons why your observations are a little off base, but the Augan is the most compelling.
I talked to some people from Sonic Foundry at their demo tent at the WOMAD USA festival in Seattle last summer. I has been some time since I encountered a more hostile reaction, or felt my physical safety under imminent threat. The cause ? I asked them about a Linux port... As for "pressure" on h/w manufacturers - you have to realize that as enthusiastic as some of us may be, electronic music on computers is currently a pretty miniscule market; electronic music on Linux is positively tiny. Manufacturers like Trident, RME aren't supporting us because of "pressure", but because they see it as the "right" thing to do, and to some extent, because they are gambling on the future (wisely, IMHO). Creative has a more compelling and immediate reason: all those consumer grade cards being installed in systems that might soon (or do now) run Linux. But try talking to a rep from a pro-audio interface company, and they may at some point ask how many units you think they might sell if they had Linux drivers. Your answer ? I feel comfortable pointing this out only because I do in fact write Linux drivers for audio interfaces, for free, and not because I see a huge market here.
"Intelligent MPU-401" interfaces are mostly of historical interest only at this point in time. Almost nobody makes them anymore, and their purpose is unclear. They existed to deal with CPU's too slow to handle a MIDI data stream. Perhaps you are referring to stuff like MOTU's "smart" MIDI interfaces. ALSA has support for the MTPAV. But these devices come with a killer interrupt frequency that is clearly not designed to work well with a multitasking OS. You're right that sync issues are tricky, but this has less to do with MIDI h/w and more to do with software that understands how to use SMTPE, MTC, MIDI Clock and MMC for control purposes. We can easily read the data via the existing driver interfaces, but there is almost no software (possibly none) that really pays any attention to it. One of my programs, SoftWerk, allows the use of external MIDI Clock as its clock. The version that does this, however, is not yet at softwerk.sourceforge.net, but hopefully will be soon. And your comments on the difficulty of writing the stuff and the size of the market are completely correct. I write Linux audio/MIDI stuff basically full time, and its hard work that benefits very few people.
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.
Sorry, but like most of the other posts here, this one is very misleading. First of all, the SBLive is a relatively new card, and like most new cards under Linux, support comes fairly slowly until or unless the manufacturer decides to help us out. In the case of Creative, we've only had their help for a couple of months. There are cards like those that use the Trident chipset that have excellent MIDI support, especially under ALSA. Anyone who is serious about audio and MIDI under Linux should not be using the OSS drivers, commercial or free, but should have switched to ALSA already. Second, your windows system is described as if its "clever" or "advanced". I have 4 soundcards in my dual PII-450 Linux system at home; 2 of them are professional digital interfaces supporting 26 and 18 channels in and the same number out. I can use all my cards simultaneously. I have the box connected to a 16-way MIDI router, numerous external synths etc. I can get Now, all that being said, I am about the closest thing is to a professional Linux audio/MIDI developer - although I don't work for money anymore, I am free to work on Linux audio/MIDI software pretty much all the time, and I do. That does mean that I probably have more of a handle on this stuff than most Linux users. And yes, its true that we lack good sound editors and we also lack good MIDI/audio sequencers. But the idea that the *drivers* are buggy - well, just use ALSA, and then tell me they're buggy. They are a lot more robust than their windows counterparts. I know because I wrote some of them:) There is still a lot of work to be done increasing the number of good apps for audio/MIDI software under Linux. But that work is not going on in the labs at Steinberg, Emagic, Opcode, MOTU, Digidesign or Cakewalk. Its happening with individual developers working hard on trying to fill in the gaps.
Greedy ? Maybe some of us. But the "free" that many of us care about is the usual "free speech, not free beer". My opposition is not to for-profit software tools that cost more than the distribution and basic support charges. It is to closed source software. Yes, many people are rightly skeptical than you can make money from software if you give away the source, and rightly so. But don't confuse some people's opposition to companies like Borland coming into the Linux world with a resistance to paying for it: we just want the source to come to!
When I went to read the USA Today story, the banner ad consisted of the following directly adjacent two images: the left side and the right side. To save you the trouble of downloading them, I'll tell that they depict a sexual scene, and come with the words (and alt tag) "Ignite his passion tonight". Now, I have to go fix adzapper to drop those pesky banners from USA Today...
Am I the only person who breaks into a wide, satisfying internal grin at seeing the Apple "Think Different" logo atop Tux's image ? When can we expect the full page ad with our herring-stuffed friend ?
4) Don't believe what you read in the press quotes from the CEO's of other startups.
"Don't worry about our competitors..."
This is no doubt why Amazon.com (more precisely Jeff, Shel and me) spent many, many hours in its first 6 months figuring out how to build and maintain barriers to entry to keep those competitors at bay for long enough for Jeff to be able to say stuff like this.
We already have a centralised repository - it's called/etc. This works very well because it's infinitely extendable. You just add text files in whatever format seems appropriate for the application.
What application ? What about information that is system wide, and not specific to any application ? What about information shared between applications ? Why do we call gethostbyname() for hostnames, but getpagesize() for the pagesize ? Why not something more generic ?
There would be no benefit whatsoever in making this more complicated than it is. To use a virtual file system like/proc instead would be completely pointless and would only mean a huge programming overhead every time you wanted to add config facilities for a new application.
This is simply not true. If the/proc-alike is just a key-value lookup system, it means way *less* work adding config facilities. sys_config_register("myapp:foo:bar:key", "value"); Obviously, it would be a lot more complex than that, but thats about the basic idea.
Individual hand-edited ASCII config files do what we need and they are robust and independent; a more tightly-bound repository kept in memory and managed by a large program would expose the configuration data to programming screwups like the Windows registry suffers from.
Yes, I've used the hand-edited ASCII config files for more than 14 years, and I'm happy with their robustness. I am not happy with their independence.
AIX, bless its ugly little heart, did contain one idea here that it would be nice to see Linux pick up and run with, improving it as it goes. Under AIX, the tangled maze of textfiles that define system configuration are replaced by a database. There is a single, standard tool for editing the DB, which in turns means there is one way to edit any part of the system config.
I don't like that last part: a single way. What I would prefer to see is this db exported to something akin to/proc - a virtual filesystem containing textual representations of the db contents, and editable with a text editor or a GUI tool. The text editor would use the standard read/write interface; the GUI tool could do that, or there could be, as in AIX, some standard API for accessing and modifying the configuration that it would use directly.
The centralized repository for system configuration is a good idea, but only if its implementation doesn't force the use of a single tool. Can we do this better? Certainly not me - I'm too busy hacking Linux audio+MIDI apps.
I don't know where you got that idea from, but its wrong. How do I know ? I wrote the damn thing. Perl was a useful tool from time to time, but it never formed the core of anything during Amazon.com's first year.
Both the article and many of the comments don't mention the fact that there are a growing number of programmers who made enough money from "paid" jobs to have the choice not to work for money, or at the very least, to be very choosey about what kind of work they do.
I am one of those people, and I write open source, zero cost software for electronic music composition and processing. I do this as almost a full time job (well, it seems that way). I do it because I like programming, I like creating music, and I like combining both interests in a context that is free of commercial BS.
The company I helped start has produced several hundred paper millionares, and quite a few actuals. There are stories like this happening a lot these days, and it has the potential to create a pool of programmers who can choose to do things their own way.
I don't honestly know how much impact this will have, but I think that it will have some.
Slashdot Mirror
You obviously aren't familiar with the Augan II. Its a pro-level, $$$$ DAW built around Linux and X. See http://www.augan.com/ There are lots of other reasons why your observations are a little off base, but the Augan is the most compelling.
I talked to some people from Sonic Foundry at their demo tent at the WOMAD USA festival in Seattle last summer. I has been some time since I encountered a more hostile reaction, or felt my physical safety under imminent threat. The cause ? I asked them about a Linux port ... As for "pressure" on h/w manufacturers - you have to realize that as enthusiastic as some of us may be, electronic music on computers is currently a pretty miniscule market; electronic music on Linux is positively tiny. Manufacturers like Trident, RME aren't supporting us because of "pressure", but because they see it as the "right" thing to do, and to some extent, because they are gambling on the future (wisely, IMHO). Creative has a more compelling and immediate reason: all those consumer grade cards being installed in systems that might soon (or do now) run Linux. But try talking to a rep from a pro-audio interface company, and they may at some point ask how many units you think they might sell if they had Linux drivers. Your answer ? I feel comfortable pointing this out only because I do in fact write Linux drivers for audio interfaces, for free, and not because I see a huge market here.
"Intelligent MPU-401" interfaces are mostly of historical interest only at this point in time. Almost nobody makes them anymore, and their purpose is unclear. They existed to deal with CPU's too slow to handle a MIDI data stream. Perhaps you are referring to stuff like MOTU's "smart" MIDI interfaces. ALSA has support for the MTPAV. But these devices come with a killer interrupt frequency that is clearly not designed to work well with a multitasking OS. You're right that sync issues are tricky, but this has less to do with MIDI h/w and more to do with software that understands how to use SMTPE, MTC, MIDI Clock and MMC for control purposes. We can easily read the data via the existing driver interfaces, but there is almost no software (possibly none) that really pays any attention to it. One of my programs, SoftWerk, allows the use of external MIDI Clock as its clock. The version that does this, however, is not yet at softwerk.sourceforge.net, but hopefully will be soon. And your comments on the difficulty of writing the stuff and the size of the market are completely correct. I write Linux audio/MIDI stuff basically full time, and its hard work that benefits very few people.
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.
Sorry, but like most of the other posts here, this one is very misleading. First of all, the SBLive is a relatively new card, and like most new cards under Linux, support comes fairly slowly until or unless the manufacturer decides to help us out. In the case of Creative, we've only had their help for a couple of months. There are cards like those that use the Trident chipset that have excellent MIDI support, especially under ALSA. Anyone who is serious about audio and MIDI under Linux should not be using the OSS drivers, commercial or free, but should have switched to ALSA already. Second, your windows system is described as if its "clever" or "advanced". I have 4 soundcards in my dual PII-450 Linux system at home; 2 of them are professional digital interfaces supporting 26 and 18 channels in and the same number out. I can use all my cards simultaneously. I have the box connected to a 16-way MIDI router, numerous external synths etc. I can get Now, all that being said, I am about the closest thing is to a professional Linux audio/MIDI developer - although I don't work for money anymore, I am free to work on Linux audio/MIDI software pretty much all the time, and I do. That does mean that I probably have more of a handle on this stuff than most Linux users. And yes, its true that we lack good sound editors and we also lack good MIDI/audio sequencers. But the idea that the *drivers* are buggy - well, just use ALSA, and then tell me they're buggy. They are a lot more robust than their windows counterparts. I know because I wrote some of them :) There is still a lot of work to be done increasing the number of good apps for audio/MIDI software under Linux. But that work is not going on in the labs at Steinberg, Emagic, Opcode, MOTU, Digidesign or Cakewalk. Its happening with individual developers working hard on trying to fill in the gaps.
Greedy ? Maybe some of us. But the "free" that many of us care about is the usual "free speech, not free beer". My opposition is not to for-profit software tools that cost more than the distribution and basic support charges. It is to closed source software. Yes, many people are rightly skeptical than you can make money from software if you give away the source, and rightly so. But don't confuse some people's opposition to companies like Borland coming into the Linux world with a resistance to paying for it: we just want the source to come to!
When I went to read the USA Today story, the banner ad consisted of the following directly adjacent two images: the left side and the right side. To save you the trouble of downloading them, I'll tell that they depict a sexual scene, and come with the words (and alt tag) "Ignite his passion tonight". Now, I have to go fix adzapper to drop those pesky banners from USA Today ...
See: my comments on the Amazon 1-click patent. --p
Am I the only person who breaks into a wide, satisfying internal grin at seeing the Apple "Think Different" logo atop Tux's image ? When can we expect the full page ad with our herring-stuffed friend ?
4) Don't believe what you read in the press quotes from the CEO's of other startups.
This is no doubt why Amazon.com (more precisely Jeff, Shel and me) spent many, many hours in its first 6 months figuring out how to build and maintain barriers to entry to keep those competitors at bay for long enough for Jeff to be able to say stuff like this.sys_config_register("myapp:foo:bar:key", "value");
Obviously, it would be a lot more complex than that, but thats about the basic idea. Yes, I've used the hand-edited ASCII config files for more than 14 years, and I'm happy with their robustness. I am not happy with their independence.
I don't like that last part: a single way. What I would prefer to see is this db exported to something akin to /proc - a virtual filesystem containing textual representations of the db contents, and editable with a text editor or a GUI tool. The text editor would use the standard read/write interface; the GUI tool could do that, or there could be, as in AIX, some standard API for accessing and modifying the configuration that it would use directly.
The centralized repository for system configuration is a good idea, but only if its implementation doesn't force the use of a single tool. Can we do this better? Certainly not me - I'm too busy hacking Linux audio+MIDI apps.
I don't know where you got that idea from, but its wrong. How do I know ? I wrote the damn thing. Perl was a useful tool from time to time, but it never formed the core of anything during Amazon.com's first year.
I am one of those people, and I write open source, zero cost software for electronic music composition and processing. I do this as almost a full time job (well, it seems that way). I do it because I like programming, I like creating music, and I like combining both interests in a context that is free of commercial BS.
The company I helped start has produced several hundred paper millionares, and quite a few actuals. There are stories like this happening a lot these days, and it has the potential to create a pool of programmers who can choose to do things their own way.
I don't honestly know how much impact this will have, but I think that it will have some.
--p