On Fri, Oct 25, 2002 at 11:54:40AM -0400, Len Moskowitz wrote: Sorry, I didn't understand this exchange. What's being offered? Nice to see you here, Len. (We met at that NYLXS audio-related meeting a while back. Geez, when was that?) --PW Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"

On Fri, Oct 25, 2002 at 02:00:54PM -0400, Len Moskowitz wrote: What a radical concept! :-} too bad /me is too busy with endless piles of web development in tennessee. anyway you probably want C/C++ hackers, i'm too slow at that... Right... that was fun. Marco's a good guy. I wish I was back in NYC. :( -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"

Patrick Shirkey wrote: This is a topic better discussed privately. My point was that if Linux audio developers had the time and inclination to offer their design and/or consulting services to commercial companies, it's likely that more Linux-based audio products would come to market. Len Moskowitz Core Sound http://www.core-sound.com

Taybin wrote: to it's I think that it's a prime cause. I'd say that it takes a company with commercial interests to see a product through development to the point where it is ready to release to customers for sale. Len Moskowitz Core Sound

"Taybin Rutkin" <trutkin(a)physics.clarku.edu> wrote: where I don't know about "many" but it's happened to me. I've looked for software engineers to assist in developing a Linux-based audio product and had difficulty finding development/consulting help. And this was for a funded project. Perhaps I'm theonly one. Len Moskowitz Core Sound

I've only responded privately to Len once, as part of this thread, but I also got no reply whatosever. I never noticed any previous requests for help/offers of consulting positions, which could possibly be a result of me filtering attachments of many kinds. --p

Len, I agree with your point here, but do not understand the idea that "if Linux audio developers had the time and inclination to offer their design and/or consulting services" is getting in your way. Are you saying you can't find developers to hire? Or are you saying you only want to hire them for the duration of the project design? The former take a real monetary commitment to put people on staff. That's pretty difficult financially. I think that most companies think about doing this and then worry that they won't find customers because people can get free software. I'd encourage managers and executives not to think that way. I'd pay regular retail prices for any program that could compete with Logic, Pro Tools or Cubase SX on the Linux platform. As a user I feel a bit trapped that I can't get the software I want today AT ANY PRICE on Linux because the open source model makes it hard for companies to make the investment. Just my 2 cents... Mark -----Original Message----- From: linux-audio-dev-admin(a)music.columbia.edu [mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of Len Moskowitz Sent: Friday, November 08, 2002 12:19 PM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter] Taybin wrote: to it's I think that it's a prime cause. I'd say that it takes a company with commercial interests to see a product through development to the point where it is ready to release to customers for sale. Len Moskowitz Core Sound

On Fri, Nov 08, 2002 at 07:06:47PM -0500, David Gerard Matthews wrote: there are some business models that seem to work. Zope Corporation and Reportlab both seem to be doing OK, largely on the "give away the software but charge a bundle for support and consulting" model. Of course, for both of them, "the software" consists of development tools. I don't know of anyone who's tried this model with end-user audio software. I would too. In fact, i'd be a LOT happier doing that for open source software than for proprietary software. hmm... how much would you shell out for the *current* Ardour, knowing its current rate of improvement (pretty darn quick)? there's a paypal account set up for donations. Think i'll head over there myself... -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"

On Sat, Nov 09, 2002 at 07:15:02AM +0000, Simon Jenkins wrote: Like the soundart chamelon http://www.soundart-hot.com/ I've considered buying one a few times, but theres no supplied linux SDK, and I'm not desperatly fond of assembler, even DSP assembler which is comparativly nice. - Steve

[ ... ] the reason there is no linux sdk is because they don't have the time or the manpower to develop the kit. they asked me if i'd be willing to do it, but they weren't prepared to actually pay me to do so :) they are really quite linux friendly. if you have time on your hands, i'm pretty sure they'd be happy to let you develop an sdk for linux for the chameleon and give it away. --p

Yep, this is what the whole Embedded Linux market is about, and the model works in the audio area quite well. Look at DigiDesign with Pro Tools. Thee isn't a reason that they couldn't offer PTLE here if they can offer it on OS X, right? Cheers, Mark -----Original Message----- From: linux-audio-dev-admin(a)music.columbia.edu [mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of Simon Jenkins Sent: Saturday, November 09, 2002 9:22 AM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter] If they're unable or unwilling to tell the difference between "free software" and "software that is written for free" then there's probably never going to be a linux sdk for their hardware. Its just too specialised and complex for someone to do it for free, or to modify anything that's already out there to do the job. Which means they'll sell less hardware. Which means there might be a business opportunity for someone who takes a different view of things to sell some hardware. Simon Jenkins (Bristol, UK)

Paul Davis wrote: Yeah, from what I understand, it's much easier to port from Un*x to OSX than vice versa. A far greater number of *nix libraries have been ported from the *nix world to OSX than the other way around. You can even run X windows on OSX, even though it isn't the normal native windowing system, so if you didn't feel like messing with carbon/cocoa, you don't actually have to. (Although I don't think very many OSX users actually have X windows installed, nor do the vast majority care to bother with it.) -dgm

Paul Davis wrote: You're right. I shouldn't have said that. It was wrong. <begin backpedalling> What I was/am trying to discuss is whether its a viable business model, in the audio market, for companies to build custom hardware that runs open software. The chameleon provided a good discussion point for this because it uses a half-open software model so it exposes a lot of the issues. But the point I was trying to make above (that a company pursuing the open software model shouldn't expect *all* the software to cost them nothing, and most especially not the software that is most directly concerned with their own hardware) shouldn't have been directed at soundart, because that's not the model they're pursuing. A linux port of their sdk wouldn't be profitable if they had to pay for it (hence they won't pay for it) even though it would be marginally beneficial for them if it turned up for free (hence they're open and friendly to offers if anyone wants to port it). There's nothing wrong with that. And it looks like a fantastic product. They may sell me one yet, whether it gets a linux sdk or not. <end backpedalling> Your points are answerable (or at least debateable) but please take my answers in the following spirit: I'm *not* criticising soundart, or saying they've done anything bad or wrong. I *am* using their chameleon as an example to explore whether or not a fully open software model is viable in that market. Soundart have chosen to go half-open, and that's their choice. But could they have gone further? Should they have gone further? And how would a hypothetical competitor who went fully open get along? Agreed, so any software development costs they incur must be spread across relatively few customers. Could they have incurred less of these costs by going totally open? I think they could, not least because ladspa solves a lot of problems they must have re-solved for themselves. Sure they'd still have had to fund quite a lot of software development, but (in an ideal world, anyway) they'd have been funding it in inverse proportion to how much that software was specific to their hardware, ranging from 100% of the cost (for code that's absolutely specific to their hardware) through, say, 10% of the cost (other people in nearby niches are also shifting data in and out of DSPs via ADCs and DACs, getting data from front panel encoders, writing data to front panel LCDs) right down to negligible or zero cost for stuff thats ubiquitous such as the compiler. Currently they're targetting developers, but the long term plan must surely be to achieve a critical mass of software for the unit so it becomes attractive for end users to buy and use. In which case, having half a dozen open source developers on board might have benefits far beyond the sale of half a dozen units, especially if the chameleon API had been close to or identical with ladspa so that it was a simple porting job to get any ladspa plug-in running on the chameleon or vice-versa. (I'm not sure how close their API actually is. Maybe it *is* a simple job to port stuff to it, or maybe a wrapper could be written so it became a simple job). Agreed. They took the half-open software approach and, given that approach, they did the right thing to put the sdk on Windows and not port to other platforms. The position they are in now is precisely the position they should be in, having taken the approach they did. But where would they have been now if they had taken the fully open route? Somewhere better? Somewhere worse? Where could a hypothetical competitor who started now, from scratch, with a fully open model get to? Would they catch up and overtake? Would they fail to catch up? Would they win or lose against chameleon in its own niche? Or would they carve out a new niche, next-door to the chameleon but not quite competing with it? I don't know the answers to these questions. Simon Jenkins (Bristol, UK)

Len Moskowitz wrote: I was more wondering what things would be like if chameleon had been (or if a competitor's product were) a completely open and free system in software terms. Probably not much different in isolation, but with a couple of similar things going on in "nearby" niches you could see a synergy develop where everybody was selling their own specialised hardware into their own specialised corners of the market, but doing it quicker, cheaper and better. It would also make it possible for even smaller companies to work even smaller niches, since whilst hardware costs per unit do increase when you halve your production run, they don't actually double like software costs do. A proviso here is that the companies involved really would have to be selling specialised *hardware*. There are plenty of 1U racks out there which are little more than particularly flashy - and relatively copy resistant - delivery formats for the software inside them. Taking a step back from the soundart/chameleon example (which I didn't raise, but may have overpursued) I still think that "free software running on custom hardware" is *at least* as plausible a model for open software penetrating the pro-audio market as "people in suits will sell it for us". Simon Jenkins (Bristol, UK)

[ ... ] you should know that i have US patents on all the above ideas. and if they don't hold up, and its someone else who makes a lot of money selling "a box like that", i'm going to have to ... cry. :)) --p

for MacOS pre-X, stability and performance would be a great pair of reasons to do this. but now that OS X is here, and apps like logic are more or less available for it, no, i don't see much point in doing that either. OS X is a major challenge to the linux audio religious faithful. it works at least as well as linux, has or will very soon have most major apps available, runs most unix-ish software and looks nice. it doesn't help to provide open source apps and libraries, however, and this really ends up being the major differentiation between OS X and linux. i'm not going to bother writing GPL'ed code for OS X because i can't go in and check how the layers of the OS and GUI actually work. i can read the darwin code, its true, but my impression has been that the darwin kernel you can build from the code apple supply cannot replace the one OS X runs. OS X might "just work" from a user space perspective, but i am pretty damn sure that there are parts of its low level operation that require a deep understanding in order to write effective low level audio apps. linux is the only system i know where i am not blocked from understanding how *any* part of the system operates, and changing it if necessary. for many users, this translates into pain, confusion and wasted time compared to OS X. but i'm not personally interested in how easy it is to build new apps, i want to build a superb system and have anyone be able to improve it. OS X does not let me do this because it isn't as tinker-friendly as linux. --p

"Mark Knecht" &lt;markknecht(a)attbi.com&gt; wrote: Most audio companies (with few exceptions) are very small and don't hire software engineers as full-time staff. They hire them as contractors, for consulting or development-to-specification on a specific project. the software IMO, companies would make the investment if they perceived that Linux provided a significant customer base unreached by Windows. I'd guess that's one of the reasons Apple is promoting OS-X to the Unix/Linux world. Len Moskowitz Core Sound

if i was an existing audio software+hardware company who understand what linux could mean for my business, and i saw that someone had written a tool like ardour more or less on his own in less than 3 years, i'd be fairly interested in talking with him about possibilities, at least. nobody has ever offered or even talked about hiring me as an employee. only 2 companies have talked about using me as a consultant. i think its reasonable to conclude that the offers of work are not out there at this point in time. --p

I guess stability is not an issue? -- drh(a)niptron.com Great spirits have always encountered violent opposition from mediocre minds. -- Albert Einstein They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- Carl Sagan

D R Holsbeck wrote: It's not the potential drawing card that it once was. OSX is as stable as Linux, and even 'doze XP is getting there, from what I hear. -dgm

On Tue, Nov 12, 2002 at 09:48:00PM -0500, David Gerard Matthews wrote: Also, with much of the audio/desktop stuff still under development, I experienced much less of the linux/server stability... Some months ago, the alsa driver would freeze my system whenever I tried to use the sequencer interface. More recently, the dri-driver for my radeon keeps doing the same. Then again my KDE-desktop is rendered unusable from time to time by some buggy apps not to mention all the beta audio-applications which aren't stable yet. So right now, I think stability is not really an argument pro linux audio. cheers, Christian Henz

On Tuesday 12 November 2002 17:05, Len Moskowitz wrote: I don't think so - the only thing a Linux audio app has to do is be sold by someone. Then we'll all be standing around here saying "Oh, why didn't I think of that?" When I started this thread (oh, way back when) I was bemoaning the fact that Linux geeks were giving Linux software a bad name in the uninitiated and indeed initiated Linux user community. I still think they do but now I don't think that's their fault or indeed their problem. Simply: Linux geeks shouldn't have to be selling Linux software. Linux salespeople should be selling Linux software. I'm sorry if I was a bit slow here but before I didn't see it as a simple case of demarkation. We geeks should set aside our pride for once and admit that we _don't_ actually know or can learn something and work with our natural enemy (the sales and marketing people of this world) if we want to make a Linux audio a commerical success. And then we can all _really_ hate ourselves. B

<SNIP> that's not really what i meant. anybody who has read this list over a reasonably period of time or who conducts a rudimentary lookup on my name using google will very rapidly get the impression that i'm probably available for any consulting projects related to linux, audio and MIDI. and indeed, <SNIP> [MWK] Third on my list in a Google search this morning. The only comment I'd make is that the resume itself made it look a bit like you were busy with Linux Audio Systems, but if I was looking I wouldn't have hesitated to call. 1) "it doesn't crash. ever." [ well, OK, but we're getting there. ] 2) "its will never be made obsolete by an OS vendor's business decisions." most people i know consider these fairly commercially attractive. --p [MWK] People do, but Companies don't. These companies need a compelling story about how they can make money selling these products. I don't understand how that is possible today. Just for fun, let me propose a scenario and see where this goes. SCENARIO 1: Software only Company A takes a copy of Ardour and forks it. They do their own GUI from scratch, maybe based on some product they already have running under OS-X or Windows. Since the GUI is 100% theirs they don't put it under CVS. They make improvements to the audio engine and provide those back for your consideration, but you don't like some of them so they don't all end up in the CVS tree for the main Ardour program. None the less, Company A met it's GPL requirements. (I think! If not, change whatever is required to make it so.) Let's assume this takes them 6 months to get ready to sell. Now Company A has a product to sell. Nuendo sells for $1K. DigiDesign's 001 with hardware sells for $800, and 002 sells for $2K. Cubase sells fro $500. Who knows what Logic sells for anymore? Company A has just 3 software engineers on staff to do this. They earn $100K/Yr. each. (Lowish-end Silicon Valley prices) There is office space cost, amortization and capital expenses, IT costs to run this business, advertising and other marketing expenses. Probably with the President's salary the business is somewhere between $500K and $1M a year. They set the price at $500 and go to market. They need to sell between 1000 and 2000 units to break even. Unfortunately for Company A, the competitive landscape isn't flat. There's a free version out there, good old Ardour, that they have to compete against. How many people will by my Company A version when it's common knowledge that it's based on the free version. How do we convince a company to take this risk with $1M dollars? It's very difficult, if not impossible, I think... SCENARIO 2: Software + Hardware Tomorrow...

Taybin, Help me understand what libardour does exactly. It may not be the way the code is arranged, but if I take the libardour database and break it into two pieces, the audio stuff and the GUI, and I obey the GPL for that code, why does something that I write that links to it have to be GPL'ed? My code is my code. Paul's code is his. He's made the interface public. Does the GPL license really say that if someone tries to talk to a piece of GPL'ed code they have to make all of their work public also? I don't understand that part. It may be true, but I don't understand it. Going beyond that, since Company A wants to make money, the cost of licensing libardour from Paul, et. all, would be another up front cost. We haven't covered the lack of MIDI yet, so remember that there are more costs if these same sorts of ideas apply to that side. And the previous scenario was only for direct selling over the Internet, probably. If Company A is going to make $500/copy, they have to sell it for $1K retail, and there aren't too many viable options for doing that with a software only product. (My opinion. I'd like to be proved wrong.) Yeah, $100K is standard priced stuff. I manage an engineering group in India and can get support for $500-$1000/month, if you know how to manage the project. ;-) (It ain't easy!) Cheers, Mark -----Original Message----- From: linux-audio-dev-admin(a)music.columbia.edu [mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of Taybin Rutkin Sent: Tuesday, November 12, 2002 12:25 PM To: linux-audio-dev(a)music.columbia.edu Subject: RE: [linux-audio-dev] image problem On Tue, 12 Nov 2002, Mark Knecht wrote: or make it's Okay. Libardour is GPL. So any frontend that links to it would have to be GPLd too (IANAL). This could, Paul willingly, be gotten around by relicensing it from him. 66% or more of Ardour is in the GUI. If they wrote their own GUI from scratch, and did a proper job of it, I think that would be a strong selling point over a freely available version. But this all assumes that Paul relicensed libardour to some company under a non open source license. Software engineers still make that much? I thought it had dropped to the $50-$60 range. Taybin

On Tue, 2002-11-12 at 22:07, Taybin Rutkin wrote: AFAIK, LGPL allows you to statically link your own code to the LGPLed code, _SO LONG AS_ you provide a dynamically linked version also, somewhere. The reason being that if a 3rd party lib gets upgraded, you can "plug and pray" with it. That's the idea anyway. It removes the binding to the propriatory code vendor for getting upgrades on a 3rd party lib. Your code is still your own and you can still have it as closed source. There is no "viral" aspect (AFAIK). GPL on the other hand states, "you link to me in any way and you must become GPL". Simple As. -Lea.

Paul, Thanks you (very much actually) for the clarifications. They are extremely helpful. It's no wonder no one can make any money being in business of selling Linux software applications. I do not see how a company could afford to invest in this area, short of staying closed-source. Very difficult for them, so no wonder there are few companies calling Linux developers. Defining a business model that works in this environment will be an interesting problem to solve. On to thinking about hardware... Cheers, Mark -----Original Message----- From: linux-audio-dev-admin(a)music.columbia.edu [mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of Paul Davis Sent: Tuesday, November 12, 2002 7:06 PM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] image problem the two FYI: libardour doesn't contain any GUI code at all, or have any notion of any kind of UI at all. "talk to" is a loose and inexact term. if you link against a piece of GPL'ed code, and you distribute your code, then your code must be made available under the GPL. it doesn't matter whether you run-time, dynamically or statically link - if your code makes explicit calls to code in the GPL'ed library, then you can't release your code under anything except the GPL. put another way: you can use my work as you let everybody else use yours in the same way. don't want to play? no problem, just don't use my code. if your code can operate normally without my code - that is, mine just acts as an extension to your already highly functional program - then the dynamic linking "clause" in the GPL will allow you to link against my code without requiring your release to use the GPL. GPL 3.0 *might* close this "hole". --p ps. libardour is GPL'ed rather than LGPL'ed for precisely the scenario mark was outlining.

On Fri, Nov 08, 2002 at 12:45:30 -0500, Taybin Rutkin wrote: I think that the problem is that manby of us have unpredicatable workloads. Generally I would be happy to put some time into any linux project I thought was a good idea, but recently I have been very short of time. - Steve