Re: [linux-audio-dev] Read this after your first cup of coffee

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Read this after your first cup of coffee
From: Jan Depner (eviltwin69_AT_cableone.net)
Date: Wed Aug 18 2004 - 00:37:50 EEST


Damn. That was all perfectly lucid. I must be missing something ;-)
Seriously though, it all makes sense to me. (Sorry for top-posting but
I'm lazy).

Jan

On Tue, 2004-08-17 at 06:17, John Check wrote:
> Good Morning,
> Here's the position paper I drafted up. As usual I'll request that responses
> be well considered. I'll post this to my webserver after I have a chance to
> mark it up and hopefully, I can stop repeating myself and get things
> implemented. Apologies in advance for the length. Comments on what I propose
> to do are welcome, but it may take a while for me to reply.
>
> --------
>
> Legitimizing Linux As an Audio Platform.
>
> The current state of affairs WRT to Linux as a platform for audio production
> is an open question, but in my considered opinion it is technically adequate
> to start getting some real traction. At the current pace, there will be some
> truly excellent applications in a years time, but it must be understood that
> everybody has time limitations and not taking that into account is
> counterproductive.
>
> Bottom up penetration (simmer down now) is the most likely to succeed path,
> however there are some issues which need to be addressed to improve on the
> chances and avenues. These issues are outside of the scope of interest for
> most developers. The pattern seems to be the people with the highest level of
> technical expertise are the least interested in these issues and that is as it
> should be. Coders should code, EE's should handle the physics, etc. In short,
> we all need to play to our strengths, especially since most of what goes on is
> done voluntarily.
>
> The issues that are playing against the community at large are not
> insurmountable obstacles and I intend to do some heavy lifting to try and
> change things. There are several phases to getting where we need to go, but
> here are the primary stumbling blocks. First I'll layout the issues, which
> fall into two categories, then I'll reveal my strategy for tackling them and
> why I think these opinions matter.
>
> The Issues:
>
> 1) Too Much Information
> A) Unclear development status and suitability of offerings.
> B) Unreasonable requirements for list monitoring.
> C) To much time spent on repetition of information in the wrong places.
> D) Disorganized and inadequate documentation.
>
> 2) There's Only 24 Hours In A Day
> A) Unnecessarily high time requirements for building code to evaluate.
> B) A somewhat distorted sense of what musicians and pro audio need/want
> C) Nobody cares about Linux except the converted.
> D) No compelling business case.
>
> Let's break it down:
>
> Too Much Information
> Unclear Development Status And Suitability Of Offerings
> http://linux-sound.org
>
> There is in excess of 36 categories of applications listed at the above URL.
> The "Sound Editors" category alone has 35 entries just in it's "General"
> sub-category. Each of these has their own particular raison d'etre and
> diversity is a good thing, but 3 of the first 10 listed projects according to
> timestamps on tarballs, haven't had a release in over 12 months. Two of the
> ten are Java based and one is a KDE app which means artsd.
> This particular sub-category has a relatively good ratio of active projects,
> but even so this means 7 pieces of software to evaluate when looking for a wav
> editor. We could extrapolate that number, but 7 is a good start and it
> includes some of the best candidates.
>
> Unreasonable Requirements For List Monitoring
>
> We've got 7 candidates for evaluation, 2 are unavailable as Debian packages.
> This isn't a problem because I use Debian, it's just an example. This is two
> out of 7 packages that need to be built from source. Again, it's not a problem
> for me, but assuming the user isn't comfortable with that, we're down to 5 on
> Debian and probably less on some other general purpose distros.
>
> So we install our 5 binary packages and have a pretty good idea what they can
> do, but if the user wants in depth info that's not covered in the
> documentation that comes with the package it's time for mailing lists. Most
> have at least 2 lists one for developers, one for users. That's potentially 10
> lists subscriptions and 5 Wikis. 15 sources of information for 5 programs, not
> counting the man page and whatever is in the help menu.
> The key to making the lists useful is participation. If there is no traffic on
> the users list, it's a safe bet it's not because the programs UI is so
> intuitive that nobody has a question. There is a threshold of tolerance for
> user questions on the developer lists and that is also as it should be.
>
> Too Much Repetition of Information In Too Many Places
>
> See Unreasonable Requirements For List Monitoring ;)
> There is an interesting corollary here with the LA lists. I'm guessing that LA
> is supposed to be among other things, a sort of clearinghouse so that
> everybody has a place to get an overview of the big picture. I have personally
> seen a developer quote one of his own postings to an LA list in order to
> answer a specific on-topic question asked on his own project's list.
> Searching that project's list archive for this bit of info (which was pretty
> crucial) came up dry until the question was asked on the project's list and
> the person replying was helpful enough to find his LA post and answer what the
> question was. Not only was that aggravating to watch, but it was duplicated
> effort on the part of the developer answering the question.
>
> Disorganized And Inadequate Documentation
>
> It is not reasonable to expect coders to spend a lot of time on documentation.
> They can either improve the code or improve the documentation and even if we
> disregard the moving target factor, the latter isn't playing to their
> strength. Theoretically at least, if a user has a question that's not covered
> in the documentation and wants to help out, the coders will cooperate. The
> tendency is for build related questions to be well documented but stale,
> because Linux is a fast moving target with lots of parallel development and of
> course, actively maintained code changes.
>
> One common solution is to provide a Wiki so that users can maintain their own
> documentation easily. This is a good way to accumulate information, but it has
> its drawbacks. Chief among them is the requirement to visit the Wiki in order
> to use it, which can be problematic. Additionally, it's not unusual for the
> Wiki to not be accessible from the "Documentation" link and vice versa.
> Wiki's, like the rest of free software development are participation driven,
> which makes a good segue into the next part. If you had to look up "segue" pay
> close attention.
>
>
> There's Only 24 Hours In A Day
>
> I'll start out prefacing this by saying software is built for a purpose. If
> I'm looking for a new construction house, I
> can buy one or build one. I may be a big Bob Vila fan and choose to build
> one, but that doesn't mean I'm a fan of
> Roy Underhill and want to make my own lumber too. Or forge my own hammer and
> nails. Given enough stress, and
> wasted time, I'll more than likely to bail and find a contractor to finish,
> or even go buy a built house. Even if it's not custom
> and the roof leaks, the builder at least acknowledges the obligation to fix
> the leaky roof. I suppose free software is
> more like an old fashioned barn raising, but anybody participating in one of
> those sticks to what they can do and
> knows what a barn is supposed to be. Marble floors and a media center is nice
> in a building, but it doesn't keep
> the livestock dry.
>
> Unnecessarily High Time Requirements For Building Code To Evaluate.
>
> This is highly variable. Some projects have better build processes than
> others, and less bleeding edge requirements. As projects mature
> things tend to improve, but not always. It's not unheard of for an early on
> decision to leave a legacy of problems that only become more
> bothersome as time passes. It's not reasonable to expect this to change due to
> inertia, but these types of problems generate questions that fall into
> the "it's obvious to me" category. It's also not reasonable to expect users to
> either fix it or eat shit and like it. If a user spends enough time with the
> doco
> and the list archives they can usually hash it out build problems, but there
> comes a point when one either has to go "Gentoo" and drink the koolaid
> because of the time invested. (I've been there and if you're a Gentoo user who
> wants to flame me, tell me you didn't _want_ to love it after the time
> invested to install it fully bootstrapped). Or, the user gets fed up and moves
> to another piece of software. That's known as "getting burned" and it
> doesn't generate goodwill. If it happens enough times it ceases to become a
> [G|K|X]foo problem and becomes a LA problem because unhappy
> users complain loudly. Happy ones are mostly silent.
>
> What it has to do with LA is, people trying to use these programs for
> relaxation or to make a living with audio/music have time constraints too.
> One might be a tech in a going facility that got a green light to do some
> experimentation with LA when nothing else is going on, but if a paying client
> has a problem with the headphone system that the tech didn't get around to
> fixing because he was cocking around trying to find an answer to something
> that was "obvious to me" or even worse figure out why "it works for me" and
> not him, guess which facility isn't going to be testing any LA software?
> A Bob Clearmountain or Bruce Swedien certainly isn't likely to spend the time
> tweaking out a system.
> This kind of thing can fly in a weekend project studio, but if you have a tech
> with that much time on his hands, you probably can't afford to pay
> for deadwood, unless maybe you use the studio as a cover to launder money, in
> which case "free" _really_ has no place there. (If you just started
> looking at the floor and shuffling your feet, I do consulting ;)
> On the other end of it (the low, low end ;) are schmucks like me who just want
> to gig, and while I have the time and the inclination to do this,
> it still cuts in to rehearsal and promotion time, which means less work for me
> and less exposure for you. We need each other, so let's not be coy.
>
> A Somewhat Distorted Sense Of What Musicians And Pro Audio Need/Want
>
> Again, this is variable. Some applications, like Ardour and Jamin, would drop
> right into a professional setting, because they do
> what they're supposed to and the interface is what people who use these kinds
> of tools expect, even if they're not 1:1 knock-offs of commercial apps.
> Other tools like oh, say Ecasound, or Cecilia would flop, especially with the
> "prosumer" crowd that buys things like standalone HD recorders and synth
> modules. These apps may be technically excellent, but look at how many
> musicians can't even read standard notation! If these kinds of folks want to
> get
> experimental, it's power it up and twist some dials and see where it goes.
> Neither one has an interface suitable for spontaneous creative monkeying.
> Cecilia would fare better than ecasound in that scenario, but chances are
> anybody that could use either of them effectively to create traditional music
> is an EE or a CS by day. My intention is not to slam either of these apps.
> They've been around for a relatively long time for a reason; They work.
> They're just a tad esoteric for general use and fill a niche.
> I'm not aware of any commercial software that does any of these things that
> doesn't have it's share of problems too. The tendency in professional
> settings is to be conservative with revisions and put off updates until
> somebody else has tested them, or if they have on staff techs and a lab,
> stress
> test well before inserting it in the revenue stream. The difference, when it
> comes to whether or not time spent getting support is worth the cost is
> simple.
> The vendor is obligated to come up with answers and the cost is quantifiable
> up front. If somethings not going to happen, they tell you. "We don't support
> foo". You may hear "Foo will be supported in the next version" from marketing,
> but you don't see that on the homepage they way you see "Aims to support
> foo, bar and baz" on a lot of sourceforge homepages.
>
> Nobody Cares About Linux Except The Converted.
>
> They really don't. They care about quality and stability, sure, but just
> because it runs on Linux doesn't mean it's inherently stable or high quality.
> There's a joke among sound men and recording engineers that all the equipment
> runs on magic smoke. Once you let the smoke out, it doesn't work
> anymore. All that matters is that it works as advertised, and not just to the
> bean counters. A Windows power user that can put together his own
> ProTools DAW isn't going to be real interested in feeling like a noob and
> getting flack because he's not comfortable patching kernels. They may not
> even be comfortable getting DeMuDi up and running. It doesn't mean they're an
> idiot, it means they know their limitations. Fortunately, this particular nit
> is not news. Of course Macs are still solidly entrenched so that
> has to tell you something.
>
> No Compelling Business Case.
>
> Yes, I know, it's not about the money. Well, I hate to be the one to tell you,
> but as soon as you say "professional", it is. And let's face it, if you're
> a core developer and you were offered a royalty or even a salary to do what
> you're doing for free you'd take it. There's no reason you shouldn't
> benefit even if there's no legal requirement for a vendor to show
> appreciation. You wouldn't have a legal obligation to address the vendors
> requests
> without a contractual obligation now either, would you?
> Now that that's out of the way, let's consider the business angle from a
> potential user's point of view, relative to the standard arguments for free
> software.
> Joe Haxor: It runs on Linux!
> Mark Pigeon: What? On Lindows? I saw that in K-Mart, I wasn't impressed
> JH: You'll get a lifetime of free upgrades.
> MP: How often do these upgrades break file format compatibilty?
> JH: Almost never... Sometimes it happens, but somebody can write a
> filter.
> MP: Almost? What about my archived work?
> JH: And it will always be supported, because you can fix it yourself!
> MP: But I'm not a programmer. I took a course in BASIC when I was in school,
> but that was a while ago.
> JH: Basic huh? That must have been some school. That's okay though, you can
> always hire a programmer!
> MP: I'm not a software house, I do radio spots.
> JH: Well, it doesn't cost anything, so you can pay the programmer per diem
> with what you save on commercial software!
> MP: Mmm lemme call my accountant. (ring ring, yack yack) He says custom
> software isn't deductible.
> JH: It's not custom!
> MP: Hang on (yack yack) He says it still not C.O.T.S. even before we modify
> it.
> JH: Tell him you can take the money you save on software and get twice as
> much hardware, that's deductible!
> MP: But then what do I pay for bug fixes with? And besides if I bring a
> programmer in they still have to wrap their head around the
> code.
> JH: AHA! You can hire the original programmer :D Now who better to fix the
> code than the guy who wrote it! :D
> MP: You mean the guy that implemented the bugs in the the first place? What
> happens if he gets hit by a bus?
> JH: Uh, well, um, there's a half dozen guys on the team and I know the code,
> so you can always hire me.
> MP: Well.. I guess thats true, but how do I know you'll be available? I'll
> tell you what, let's talk about hardware, now what's the
> warrantee like?
> JH: That'd depend on who you buy the hardware from.
> MP: I was thinking I'd buy it from you, since you're trying to sell me. What
> do you suggest?
> JH: Let's see.. you want a Foomax2k5 SMP board with a Flaprack googleplexer
> and
> MP: A wha? Lemme ask you this, what's it cost per I/O channel?
> JH: Depends on what you want.
> MP: I want to go have lunch. Go work up 2 year lease price on 24 channel
> system with a years support and 24 hr on-site emergency
> response and fax it to me when you have a number.
> JH: Why would you lease?
> MP: Okay, I have a business lunch to get to, let me walk you to your car.
>
> The moral of the story: There is no such thing as free and people have things
> to do.
>
> So What's Your Plan Smartass?
>
> First thing is to improve the documentation factor to help make things easier
> for the brave. Right now it's a Gordian knot and here are what the scissors
> look like. I expect we all know what a MIDI implementation chart is.
>
> I'm going to whomp up a database driven reporting system that extends the
> concept to include protocol and library support and has some
> Wiki like features. One will be able to search for specific types of programs
> with specific criteria like:
> Sequencers with LADSPA, JACK, DSSI, MESS, OSC, PHAT (Yes PHAT is that cool)
> Hits will come back in table form with checkmarks in the appropriate columns,
> ranked by how much of a match and a "freshness" date.
> The app name will link to the project site and there will be additional links
> to the primary documentation and the Wiki, if one exists.
> There will also be a link to and reporting form for an MI chart.
> Forms will be radio buttons/check boxes/combo boxes.
> The only text input will be for URLs. This should minimize grammatical and
> language issues as well as make internationalization easy.
> Links will be validated at a regular interval and 404's will generate an email
> to me, or if someone has taken responsibility for a project, that person.
> Bounced emails to that address will be returned to me for further
> investigation.
> This is intended for both developers and end users. It will take no more than
> 5 minutes to file a complete report.
> This may sound like a burden for the developers, but no more than a Wiki is a
> burden on users. I'll prime the pump with some reports on what I use myself.
> Newly interested users looking to help out on projects should find filing a
> report to be a good way to begin.
>
> This by itself isn't quite enough, but it's a start. I'm also planning on
> subscribing the system to the LAA list or possibly spidering
> the list archive for announcements to get the ball rolling with automating
> some of the updating. As far as library support goes, I'm going to keep
> a CVS tree of what I consider to be the cream that will be cron'ed to update
> daily, then recursed and diffed for new options in configure files. New
> options
> will initially generate an email to me, and if all goes well will eventually
> report directly to the system.
>
> I would appreciate any ideas on what should be included, but I'm not going to
> get into extended debates about what should be in.
> I'm the ultimate arbiter, at least until it debuts. The basic manual reporting
> and search should be live in 7-10 days.
>
>
> What About The Business Angle Then, Donald Chump?
>
> That's the easy part. I'm laying the legal groundwork for becoming a vendor
> and support channel for turnkey systems. There is a lot of
> money spent on this kind of stuff and if price is a factor, it only takes a
> few dollars difference. Anything more than that is counter productive.
> If you don't believe me, have a garage sale and put out a box of "free" stuff,
> then after an hour or two put "$1" on it people might haggle you down but
> it'll move.
> "Linux" will be on the last page of the brochure. If all goes according to
> plan the biggest chunk of revenue is going into R&D, which means to guys
> who've been doing heavy lifting on the core apps.
> Anything they're not interested in gets farmed out, most likely on a bounty.
> Despite the apparent lack of popularity of the idea, it will have distributed
> processing as an option. This will allow for incremental penetration and
> interoperability with
> existing systems. Depending on the budget one has there are more ways to skin
> that cat than the plugin route. We have MADI support on the platform
> for the high end and good old coax for low end applications like live FX
> processing.
>
> And there you have it. Why these opinions should matter is self evident.
>


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Aug 18 2004 - 00:41:50 EEST