Wise words I intend to live by. Photo (CC-BY-ND) Geof Wilson.

I’m a blogger. I’m supposed to be all about shiny, about scoops and exclusives, about fast-paced development. But even I’ve begun to wonder about the expectations some developers and users alike have about pace. And that doesn’t just apply to the vendors: it applies to writers and users, too.

One theme repeated again and again by developers around NAMM: let’s slow down. It’s not a new idea, but several recent developments make it doubly relevant.

Two hardware products revealed this week in functioning, working order had been separately accused of being vaporware, because they didn’t come out right away – perhaps an indication of the increasingly-compressed perception of time in technology. The Beat Kangz Beat Thang drum machine and Teenage Engineering OP-1 synth/sampler/instrument are now each nearing shipment. Now, I expressed some skepticism about each of these products, only because I tend to believe what ships — too many gorgeous prototypes have wound up unraveling along the difficult road to market. Yes, I even poked fun at the OP-1 for pushing my “awesomeness versus shippingness” continuum. But I’m not surprised that the gestation of these two tools has consumed some time. Frankly, it’s gotten to the point where I feel some relief when I hear about delays. Efficient design can mean faster development, so delays can be a bad thing. But if you really care about quality, sometimes you miss – or don’t set – deadlines.

On the software side, people are still talking about Ableton’s decision to freeze development to fix their software. It’d be a mistake to read too much into that: the 8.1 release of Live wasn’t up to their quality standards, and I’m convinced the underlying process will be improved so that future quality is better. But this goes beyond Ableton.

A correlation of this announcement is the realization that software doesn’t have to ship with bugs. Some tools in our industry simply ship too early. Beyond bugs, there are products that ship with important features missing, or incomplete realization of their ideas. There are products that should have gone through some revision that don’t. There are features that should be taken out and wind up getting left in. Some of this has to do with syncing up with distribution and marketing, but at least the rest of us can adjust our own expectations in regards to the parts of this process we do touch.

Gino Robair has a superb essay on this topic, spawned by the discussion here on CDM and what you readers have been saying:

Why Is This So Complicated? [Electronic Musician Robair Report Blog]

It’s worth reading his whole essay, which also responds to concerns that those of us in the press aren’t being fair and impartial in our reviews. But I want to highlight this passage, because it suggests that the industry can change:

Kirn notes that “all software has bugs.” Perhaps. But wouldn’t it be great if developers came clean and told us what the issues were when their products were released? Better still, wouldn’t it be a win-win situation if manufacturers didn’t make promises that they couldn’t keep about features, but only announced things that are fully functional, perhaps adding extra features in .x updates. Imagine if a developer announced and delivered a bulletproof version of their new audio app, then named five state-of-the-art features that would be added incrementally over the next few months in free updates to registered users (perhaps after they were bug-fixed using public betas).

In fact, as a certain developer noted, you shouldn’t even need a public beta to fix bugs. Adding features doesn’t have to mean adding bugs, because properly engineered, those features would work reliably from the start. Getting testers to find the bugs, or even producing those bugs in the first place, is a cost that should be avoided wherever possible. The goal of any engineering effort should be to stop bugs before they’re created, not test them after they’re created, or worst of all, ship them to customers. Prevention is the best medicine.

This sentence from Gino could be framed and hung on the wall of every software developer. (Actually, I say “developer,” when I should say “manager” – most developers are more than aware of this issue.)

Unfortunately, the industry is training an entire generation of users to wait for the first update before upgrading their apps.

That’s the crux of the problem: it’s one symptom of an epidemic of lowered expectations. Incidentally, when I said “all software has bugs,” I didn’t intend that as an excuse. (I actually got a couple of notes from prominent developers about that who passionately disagreed, partly because they have invested time to avoid just that!) Any software has the potential for failure under specific circumstances that may not be immediately discovered. In this case, though, the point of contention is really known bugs. And those don’t have to ship. Cosmetic issues often do ship, and that’s fine. But music software should be considered “mission-critical,” because to a musician, it is.

It’s known by different names, but most developers, regardless of industry, refer to certain issues as “known but shipping.” If that bug is something more serious, like a crash, it really isn’t okay.

By the way, if you think this is just about software, I think you’re mistaken. I’m biased toward the value of software, but I have to take issue with Gino Robair’s criticism of software’s disposability. I couldn’t agree more — on the software side, that is. I just happen to think it applies to hardware, too. As Gino notes:

Some announcements, however, just seem to pile sexy new features onto an older product while core issues remain unsolved.

Sounds to me like that applies to a lot of hardware electronics, too. And while traditional physical, acoustic instruments have extraordinary longevity – ask a 17th century viola da gamba – a lot of modern instruments, especially electronic ones, are designed to be as disposable as software upgrades. Also, at least a software update doesn’t impact the environment; electronic instruments produce toxins and consume energy in their construction, disposal, or both. (See Gino’s original editor’s note, which focuses on guitars. Gino would no doubt approve of the CDM readers still using their Commodore 64s.)

Simmering leads to deliciousness. Photo (CC-BY-SA) EraPhernalia Vintage.

If we want this situation to change, all of us – not just vendors – will need to participate. All of us are to blame, not just developers. As users, we often ask for more – more features, more stuff – and we want it more quickly. There’s nothing wrong with that, necessarily. But we should also reward developers when they focus on improving quality, and some of the things you can’t see. Because I know we users care about those things, we should be willing to wait for upgrades if that wait pays off in quality, future-proofing, and stability. It’s not wrong to ask for more, but we should be prepared to wait if we want that “more” to actually work. Needless to say, it’s also important for users to invest wisely in software that has value, as some of these pressures are financial.

As writers and publishers, we sometimes aggravate the problem, as well. If we’re reviewing a product in a non-shipping version, we should identify it as such. We can all take the opportunity to review products not just when they’re new, but when they’ve been out for a while. (In fact, readers, if any of you want to help me with some “long-term” reviews of software — tools you know even better because you’ve used them for months or years – I’ll be making that a goal.) We also often look at the presence or absence of features in a vacuum, because that boils down nicely to “Pros” and “Cons” categories. It’s always a challenge, but we can try to go beyond that one dimension.

I don’t want to speak for any writer or publisher other than myself, or criticize any outlet or writer other than myself: this is directed primarily at me, because I’m the one I can control. So I’ll just say this: I’m ready to commit to spending more time with tools. That’s the way I work in my music, so that’s the way I would prefer to write about things. I still believe in getting information out there quickly, because on the Web, you get corrections, clarifications, and new knowledge more quickly as a result. But it’s possible to do that, and spend time on really getting deeper in topics. I also believe it’s important to focus on more than just “news,” which is especially tough – but also especially valuable – on a daily online site. I’ll take that as a personal challenge to myself — it’s New Year’s Resolution season, anyway.

Speed can be a wonderful thing. When I’m teaching, I regularly encourage students to sketch code in a day. Deadlines can be liberating. A number of creations I saw at NAMM got prototypes wrapped up in the days leading to NAMM, so the trade show itself can encourage the forward progress of development.

But some things are important enough that they take time. Sometimes, engineering a solid foundation means being patient now in order to save time later.

I can say, I’m seeing encouraging signs that a lot of music tech vendors are ready to get off the treadmill. I heard repeated again and again “we took longer with this, because then we could do it right.” I can’t imagine anyone complaining about that in the long run.

The food world has slow food, a movement that encourages sustainability, quality, health, local tradition, diversity, and taste. It isn’t just about the food: it’s about how that food is consumed and appreciated by the eater (read: user). I think we need “slow development” in hardware and software. All of the same issues are at stake. Even labor and environmental standards are issues, because music gear and computers, like agriculture, are now globalized and mass-produced.

Nor does this have to apply exclusively to the vendors at NAMM. All of us have projects, technological and musical, that could benefit from our own patience. It could be your new hardware controller, or your new album. The Internet age can be intimidating, as we see people making incredible progress and showing them off in just-uploaded YouTube videos. But each of us has a pace that’s appropriate for each process. Making things and making music should be an enjoyable process. If we’re slower than someone else because we’re learning, because we want to take extra time to work out the details that matter to us, we can savor that. We can give ourselves the time we deserve. That’s likely the first step to being patient with everyone else.

Ultimately, the choice comes down to us. It really is possible to derive new value from slowing down.

  • Yes, this gives me hope ! Bravo!

  • Ulhuru

    Try GR 4 !

    This could deserve big time being slowed down the Ableton way! (Abletonized??)

    Support at NI would love such a move…


  • I'd love product development to slow down. I believe it will anyway, during years of recession; and, if it's true that we're no longer discovering fossil fuel as quickly as we want to burn it, and we don't manage to find other sources of energy, electronic product development might be about to slow down quite a lot.

    But software development definitely DOES impact on the environment: developers drive to work, servers and server room aircon burn plenty of energy. Keeping a server going for weeks so that customers can download a point upgrade of a VSTi… versus 200 CDs in the mail… Interesting maths 😉

  • leytonnz

    as a pro user id love to hear that logic went on to a feature freeze and a bug squish period..

    i hate the whole "but they've known about this bug for years" feeling that i sometimes get..

    or " that menu function doesnt do what it says it should"


    i personally have more than enough features to make a living making music.. id like stability and the feeling that a legitimate bug was actually being taken care of..i applaud abletons recent stance.

  • golden master

    yeah, and on top of that, slow down with all the crazy feature additions. modern music apps, almost all of them, need a lot more focus. That includes, with the software I've used, or have used, ableton, FL studio, Logic, and so on. Some developers, like cockos, or ross bencina of audiomulch, or the renoise crew, five12, seem to have it right, where they are focusing on a more specific vision for their software. But most other devs just seem to throw as many features in as possible so as to attract a broader user base. What a mess!

  • aws

    its not the development that slows down, its our expectations that need to be more realistic and informed.

    the product-marketing-people have taken the theory of planned-obsolesence and applied it to software. not only is that a backwards idea in general, its particularly wrong in the case of software since digital information has no natural rate of decay.

    there is a myth that the software market has a fast turnover rate, and this is simply wrong. the data does not support it. major software packages have lifespans of many decades. lotus notes, photoshop, word, emacs, cobol, windows… even hardware apis, x86, ppc, mips, all very old tech and all in use today and with no end in sight.

    the tech industry as a whole does us a disservice by ignoring this fact and refusing to make maintenance and quality a priority. there are a few exceptions but they don't tend to be consumer-oriented.

  • I can't help but feel that a large part of these problems stems from the need to release new products to satisfy the markets and share holders.

    Although in Apples case you have to wonder since Logic must be such a small piece of their pie.

    Overall, as consumers, we have come to expect big gestures from software manufacturers. Sometimes it's almost like development within tech is more important than musical developments. The irony here is of course that musical genres that have a strong foundation in technology rarely have a need for the latest and greatest (D&B – Akai s3000), and it's more often the old bog standard mainstream music that seem to utilize the latest feature to automate music production (Autotune, drum replacing et al).

    The truth is that we get what we deserve. Praise change by buying into it and that's what you get. It's in the nature of geekdom I guess – we simply get too excited about new fangled stuff 😉

  • Jim Aikin

    Given the complexity of the software we're working with, expecting that better engineering will squash bugs before they get to alpha-testing is … well, it's optimistic, I think.

    A quick story: I was told that in the waning days of Passport Designs (remember them?), a product HAD to ship, because the accounting department had to show it on the balance sheet — but it COULDN'T ship, because it was still too buggy. Apparently, empty shrink-wrapped boxes left the loading dock…. This is an extreme case, to be sure. The point is, I don't think programmers, users, and journalists can shoulder all of the blame. Ultimately, it's a management problem. Managers (pointy-haired or otherwise) whip up expectations and then demand that the coders satisfy them by such-and-such a date. The rot starts at the top.

  • @Jim: Well, no, I mean that should be the goal. The more bugs you can eliminate or prevent during development, the better. You can still have some sort of testing and quality assurance to assure you don't ship whatever remains.

    But yes, absolutely, a lot of this comes down to management. No argument there. That's why it's encouraging to see Gerhard trying to do, I believe, the right thing at Ableton.

  • Joshua B


  • Gavin@FAW

    I don't think the development time is as much an issue as the yearly cycle of paid upgrades. If we were to freeze feature development of all the currently released software, would the we all become more productive in our music making because of it? I think yes. Would we miss the additional features that get added in each update iteration? I think no.

  • low resolution sunse

    Spinner brings up a good point: a lot of really good music was done on (what is now) aging gear. I know I'm certainly guilty of trying to 'buy inspiration' instead of just getting my work done.

  • Propellerhead Software. 'nuff said.

  • Jonkunu

    This is nothing new in music technology. Propellerheads have been doing this for years. Funny have people bitched at them for taking their time.

  • Jonkunu

    Well said Robtronik, well said.

    Reason/Record=Replace buggy software

  • I don't think the issue with some of these products is necessarily that consumers are so demanding that developers are forced to release before they should. I believe that this culture of internet announcements and press releases month [and in many cases years] before a product is ready for show create a snowball of hype that eventually gets out of control. We started talking about the OP-1 in 2008. It looked cool. I wanted one. Now its 2010, where the f*** is my OP-1? Its a natural reaction. If developers don't want consumers to be so demanding, then keep your project under wraps until its late beta stage. Then hype it up for a month and make it available for sale. Honestly, in a scenario where making bold announcements about a revolutionary new product that everyone will want and then not delivering for 18 to 24 months, who wins?

    How about this scenario, here is an awesome new product we've been working on, its really cool, and it ships in 2 months. Its only worked for Steve Jobs for about a decade now.

  • Gavin@FAW


    If you are a new company and releasing hardware, you have to show it pre-release at a show like NAMM so that you can build up your distribution network.

  • jg

    Um, you guys realize that the vast majority of bugs aren't known by the developer? It's only when some enduser happens to use the software, to the extent that the enduser discovers the bug, that the developer finds out about that bug. I don't test my software as much as an enduser does because lots of my time is spent coding and debugging whereas _all_ of an enduser's time is spent operating (read: testing) the software.

    You guys make it sound as if developers are intentionally putting bugs in software, and intentionally leaving them there.

  • I realize I say "new" here – I guess what's interesting to me is that people are hitting this point more emphatically than perhaps they have recently. It's not a new idea.

    Actually, I talked a bit with Propellerhead about their process. Indeed, they have a rigorous process for trying to prevent bugs before they happen. I think it's worth visiting how the Propellerhead folks do engineer their products generally, and how they think about them. But this isn't something that Propellerhead are exclusively capable of making happen. One thing that's different about Propellerhead is that they don't do these announcements of new features and timelines.

    @Mike: That may be. But let's take the Beat Thang as an example. They showed early prototypes, and got feedback they're incorporating into the final product. As a result, it may be closer to what people really want. If you want something and then cease to want it a year or so later, only as a result of having read about it, is that something you really wanted to begin with?

    I've read about, say, automobiles from Maserati. I don't cease to want one because I've heard of / seen pictures of a Maserati. (I, uh, can't actually afford / park / drive a sportscar, but you get the point.)

    So, yes, manufacturers: please continue to give us information.

    @jg: Testing can be important. And of course no one is intentionally making buggy software. But it's possible to reduce that load, or even in some cases eliminate the necessity of user testing to find bugs. I think it depends on the number of variables. An operating system obviously benefits from widespread testing, because it has to interoperate with drivers and software and such. On the other hand, testing alone doesn't necessarily make more reliable software.

  • @Robtronik

    Doesn't mean because you didn't experience anything that it is bug free. I ditched reason because of a 2.5 bug. Didn't get fixed till 3.0.4 which was a paid upgrade.

    If the industry slowed down any more it'd be at a halt. I wouldn't call a period where everybody is catching up to each other the golden age of DAW's.

  • Having been in software development since 1995 I can say with the utmost confidence 'speedy development' is not in anyone's best interest. I am all for agile development, scrums, stand ups and the whole nine, but if you stuff doesn't work, it was all for naught.

    Personally, what gets me is the software company that takes FOREVER to post a new release, then when it comes out it is even more of a train smash than the previous version. I shall not name names. 🙂

  • herenlt

    @Bjorn Vayner

    out of curiousity… which bug did you encounter?

  • At the time I was using Reason, Live 3 and Plogue Bidule. I had reason crashing all the time when I triggered a sequence. Which then was done by assigning the same note to a clip in Live and an action in bidule. Live 4 came and I didn't use that setup anymore till the Reason 3 beta started. Reported it to Louie from the props, but by the time 3.04 popped up I had sold reason. If I recall correctly, it wouldn't load some of my older projects either.

  • Jaime Munarriz

    Reaper is a model of constant, transparent development.

  • Detroiter

    As a user/musician/entrepreneur, I definitely appreciate the move to slow development. Often ideas which spring from existing technology take time for the solo artist or lone entrepreneur to develop and showcase. The creative ecology of each level of change is lost when we rush into 'whats next' too quickly. Stew eaten the 3rd day always tastes better than fresh or day old.

  • Fantastic last paragraph in particular Peter, I couldn't agree more.. something to always keep in mind.

  • greg

    How come we never talk about the ethical and environmental problems caused by products? Reading blogs, forums, articles and reviews about music tech and products for more than 10 years gives me the impression the musicians don't give a s*it about the environment and the people who manufactured the product. Most hardware products contain some toxins (mercury, cadmium, etc) and had to be disposed at some point. Also, many products are manufactured in Asia for ridiculous salaries and in horrible working conditions. How come we never talk about these things? Does anybody care about it?

  • I want to say that those are two good point that I had not really considered.

    To FAW Greg: I never really thought about distribution networks. That makes sense. I think the frustration lies in some of these products that make bold announcements, then don't deliver for years. Most products don't do that. Taking Circle as an example, I recall some interesting pre-release announcements and shows of great promise, but not YEARS of lead time that leave your audience disillusioned.

    To Peter: First, let me say great site. I'm a big fan. I link you from my personal blog, and I know the DJ Tech Tools team [who i write for] are big fans as well.

    I didn't really think about user feedback effecting the final outcome of a product. That seems completely reasonable. My point was really more about being disillusioned with over-hyped under-delivered products we hear about for years but never get to play with.

    Good points. My perspective is that of a consumer. Being a developer / small business owner I'm sure brings challenges many of us can only begin to fathom.

    RE: Bug Squashing. From years of working on Fortune 500 company software I can tell you its not possible to squash all the bugs. The best you can do many times is hope to ship a stable 1.0 and have a strong support net to develop that 1.1 release once the "real" end users start reporting problems. You can never anticipate exactly how the end user will actually USE the software.

  • wa

    totally agree with mike that early announcements could create a snowball of hype.

    and it's not the only effect they could have.

    think about Celemony:

    – they showed a preview of their technology

    – they took their time for doing it right, (in a way following slow development idea).

    What was the result of that?

    A lot of pressure and people that started telling around their technology wasn't real.

    avoid the hype and avoid promising things

    until you are quite sure you can deliver.

    It's all about expectations.

    How they are created, how they grow, how they are fulfilled (or not).

  • Well, of course, people thinking technology isn't real means those developers get twice the satisfaction when they can bring it out. So I'm not sure that really impacts the developers. I think if your previews look good enough that people think it's all magic and voodoo, you're probably doing something right. 😉

    @greg: I'd certainly like to investigate those environmental and labor issues more. Toxins – that's pretty straightforward, actually. The good news is that some areas are getting better, like the shift to LEDs from Mercury-containing LCDs. The bad news is, of course, there's still a lot of toxins produced in the manufacturing process itself, in power generation for manufacturing, in power consumption during use, baked into the products, disposed with the products…

    On the other hand, you can reclaim some of these heavy metals if they're disposed properly. So it shouldn't only be feeling guilty about consuming electronics – we should look for decisions we can make to mitigate their negative effect.

    I think the reason labor issues and the ethics around that aren't discussed, aside from it being an awkward issue, is that it's more difficult to get information. "Made in China," for instance, could mean a whole range of environmental and labor policies from those that are very poor to those that aren't. And sorting through contractors and sub-contractors and such can be a challenge.

    I think that'll require more research, but I'm game.

    I also think it's pretty safe to advocate local production wherever you are – if you're in China, if you're in the Netherlands, if you're in Belize, wherever. Local production of even some components means that you build competency in manufacturing where you are. And that should theoretically make for a more diverse, more level playing field. It's never an entirely simple issue, and perhaps there's a balance, a time when it makes sense to import goods or parts.

    But I'm all for talking about it. I think some people here care, yes?

  • wa

    A lot more developers than the customer's would think of, don't really care too much about bugs in the software. In the end they do what they can, and as long as the software keeps selling, they get paid for it.

    Isn't slow development something for developers (and manufacturers) who care?

    don't want to be polemic but:

    'people thinking technology isn’t real means those developers get twice the satisfaction when they can bring it out'. exactly! 'can' bring it out means that it's true only if what they bring out is actually what they said they will bring out.

    'I think if your previews look good enough that people think it’s all magic and voodoo, you’re probably doing something right'.

    OR you're probably just doing what all magicians are good at: let you believe that what you're looking at is something when in reality is something very different.

    I mean Melodyne DNA it's great but it's very, very far from what they actually were trying to let people believe with their demos. I bought it and use it and think it's special, still it's not what they have been advertising.

    'not sure that really impacts the developers'

    so are you saying that hype, promises, marketing, advertising and messing up with customer's expectations has really nothing to do with how fast or slow, how good or bad the development goes on?

  • @Peter Kirn, who wrote "Sounds to me like that applies to a lot of hardware electronics, too." I absolutely agree with you about that. The ultimate goal is to have something that lasts and that you can use, musically, for as long as you need to, whether it's hardware or software.

    If someone's still using a Commodore 64 for music, Amen — I want to hear it! (I loved using the Amiga for video work, and wish I still owned one…) There's a place for so-called "obsolete" technology in music: 8-bit, cassette, tubes — they've all been called useless by marketers touting the next generation of gear. But some of the best music being created right now mixes all of these technologies, and then some. (Personally, I like my 12-bit sampler. Run it through an amp or some modules and it's even better.) One of my favorite laptoppers, Tim Perkis, is still using the same laptop, software, DX module, interface, and MIDI mixer he's had for, what, 15 years or more. It's his instrument, and he knows it inside and out. He's a coder, but he settled on something and dug into it. I admire that.

    And that last time I saw Robert Rich play, he was using a first gen Mac laptop to run his analog synth.

    Thanks for running a great forum, Peter. CDM is an invaluable resource.

  • @greg, who wrote "How come we never talk about the ethical and environmental problems caused by products?" That's a great question, but very complicated, because it probably involves every segment of the music-instrument manufacturing community — manufacturing, shipping and distribution (carbon footprint), packaging, disposal. Look further, and you'll see that it extends also to exotic-wood instruments and deforestation. (Google "Gibson Guitar CEO Leaves Rainforest Group After Nashville Raid" for example.)

    At NAMM last week, there were picketers protesting the treatment of Asian laborers who build guitars for Fender and other companies. I'm not sure if it got any media coverage, but I do know of one person who says she plans to put up some video-interview footage about it soon.

  • David Prouty

    It seems like Cockos Reaper puts out a new release every three weeks or so. It is always very stable and fairly cutting edge. They cant have a very large team so how are they managing to do this? Maybe the large companies should take note.

  • It 'a big concern … recently in Italy was identified by many enterpreneurs as one of the major underlying causes of the crisis, 'gain the maximum possible without considering the future conseguences'… basically satisfaction in the short term. Consumers today are themselves too greedy and impatient… somehow the trend has slightly conformed to this behaviour (consumerism)… I think anyway thanks to the activity of independent figures, such as CDM but also many enthusiasts who populate the web, it becomes possible for the 'skilled consumer' to become the lever that will slow down this trend.

  • Flipside

    Why developers should slow down?? Competition and high expectations from users is what makes this industry so lively and flourishing in terms of innovation. Look at Apple for instance. They are in a situation of "monopole" in their market (i.e. the OSX and Mac related products). Result? Even though Apple makes great products they hold everyone by the balls, market their product however they want and price them accordingly to…well how much Steve jobs want you to pay for them. Result, great stuff but it takes ages before to have a real upgrade and products are often consciously underdeveloped to make sure that buyers will get an upgrade the year after (e.g. iPhone). If you start buying into this you will end up being taken in hostage by those companies. So more competition, more choices and a fast turnaround of products to let users judge of the importance of a product!

  • That's something that's always intrigued me about the music software industry. I only pay a little attention to it, mostly through your blog, and it seems that everybody caught a compulsive announcement-making disorder. I see products being announced and demoed, undoubtedly to create a buzz, but two years later the product still isn't released! It's hard to be surprised when people call vaporware, and I don't see how this is any good to their business.

    In my only 13 months of having a product for sale, I was able to verify what I already suspected : when the web is abuzz with your product, when your YouTube videos are embedded by the dozen, when every website and blog reposts the first paragraph of your website's front page, you want to make sure that people can give you their money while they want to, and you want to make sure that what you're shipping is what's advertised.

    Mostly when you make extraordinary claims! I've never made any claims that couldn't be reproduced immediately by any user, yet I've been accused of elaborate hoaxes due to the extraordinariness of my claims/demos. So imagine making claims two years before you can ship! Why do people do that? You'd think they'd want to keep all their media thunder for when they're ready to take your money, right? Wouldn't it be so much more huge if you sneakily dropped a bomb like Melodyne DNA when it's finished/polished as hell and anyone can try it/buy it than when you create a huge buzz and then eons later go "hmmm okay a beta is out now, do we still have your attention?".

    (Oh, and you so want to make sure there's no bug! I haven't had any report of any significant bug in over 6 months, and it makes me feel warm inside to know that half of the Internet can raid my webpage, my mailbox won't be filled with any bug report, only people who don't know how to unzip or people who want to know how to make acapellas.)

    Also, why does commercial audio software have slower update rate? And why do they go from major version to major version? Why not adopt a more progressive style? As in, adding/fixing things progressively and regularly instead of dropping a yearly update that's going to bomb out because oh surprise you added bugs with your new features. That sort of release cycle just make things look bad, as you said, it lowers expectations. I tried 3DS Max 2009, and the damn thing kept crashing on me all the time, and it was the same for the other users I talked to! Every year, every release, it's the same, and you have to wait until a patch is timidly pushed out the door. That damn software must be have been in development for like 20 years, yet it still ships with show-stopping bugs? Obviously something is inherently problematic about the one major release + a patch every year release model. It's not like their major version number is even deserved, by deserved I mean it should be when you change things in a radical way, not when you add a few cool features and change the skin. And I think there's something to be taken from the FOSS motto, release early, release often. Mostly release often.

  • The ubiquitous breakneck pace of life and peoples' expectations of instant gratification threat the well being of us all!

    The whole anglo-saxon/european world (at least) is a captive to a very superfluous culture where image and effectinevess are the merits people & products are valued for.

    I still haven't met with too many updates or new products that have made that much more productive, or enjoy my procuction process more.

    But if you know something more cool and sexy is out there, or even better just around the corner, you just must have it…

    I think it's the same with peoples' jobs, relationships, and everything right now. We live in a megalomaniac culture where everybody feels like they have the right and possibilities to have and accomplish just about anything… And when they can't, at least create a sleek Facebook account where they can try to make themselves look like the 21st century übermensch everybody should be…

  • With respect to your wishes to have a bug free program while not impossible this problem is considered intractable, which is an optimistic way of saying impossible.

    Mathematicians call this a satisfiability problem and they are currently thought to be NP complete which are thought to be intractable. Some hope that the Quantum computer will be able to attack this issue in the future but that still in a long shot. For more on this check out:


  • Pingback: Create Digital Music » A New Theme in Music Technology: Slow … | Xtreme Geeks()