The Pro 2 and Tempest are not similar in terms of complexity or length of development, nor were they released in similar states regarding the initial OS. Your comments are both non-constructive and misinformed. A number of regular contributors are able to voice their opinion without being rude and combative. This is by far the best way to get us to engage because nobody likes to have to defend themselves right from the start. Please keep your comments constructive. You did get the development rate correct, though. We have long product cycles compared to most consumer businesses, and it is years of OS development for our instruments as I will explain below.
First, as a fellow synth-enthusiast and musician I'd like to say that like you, it is also difficult for me personally to wait for bug fixes. Why? because *my* bug is always the most important, of course. Ha. This can make it hard to watch other bugs getting fixed or other instruments getting updated.
Second, we love using our gear too! After all, we work for a fantastic synth company that makes amazing instruments and we're all musicians on some level. We're not just trying to turn out a "product" for "consumers". We love what we do, and we put tremendous effort into everything we design. This is because we want to make interesting music gear that people will love as much as we do, not because we're only concerned with the bottom line. If that were the case we'd manufacture overseas, buy the cheapest components possible, put everything in plastic enclosures, and spend more money on advertising than product development.
With that understanding, I would like to share Dave's strategy on OS development with you. This post isn't meant to act as the be-all, end-all post in this thread. I just thought if you guys had some insight on how we operate in terms of OS updates it might give you a better awareness of why things happen the way they do, and perhaps keep things more conversational instead of repeatedly voicing your dislike for the current state of XXX instrument's OS. Negativity on top of negativity is a downward spiral and it's easy to get stuck in that loop.
As we've mentioned previously, no amount of ragging on a particular issue or instrument is going to get it fixed any faster. I'm saying it again because this statement is absolutely true and often overlooked. This isn't because we turn a blind eye towards bugs and we don't listen to our customers. It's because there's a system in place for how the company operates, and Dave vigilantly adheres to this system regardless of any external input.
We take bugs very seriously. When they are reported, if we can recreate them they go on a bug list which is constantly maintained.
So, onto the OS update timeline. How does this work? Dave's approach is the same for every instrument's OS development cycle so this applies across the board, no instrument gets preferential treatment. This isn't part of a documented business plan or anything, it's just my observation of what happens after being involved in more than 15 product development cycles over my years with Dave at this point.
In the beginning, we design and develop the instrument. We extensively test the OS both internally, and externally with synth-experts outside the company. We fix everything we find before we start selling the instrument. Then, we release it with version 1.0 software. Let's call this stage one.
Believe it or not, for most users the 1.0 OS is sufficient. The instrument works and sounds good. I can't tell you how many support requests and repairs we get everyday where the synth is still on the 1.0 OS or whichever OS version their instrument shipped with even if there have been numerous updates. Most instruments we see for repair also don't have a single custom program on them, they're still loaded with the factory programs. This is true for the vast majority of customers we interact with, and by a landslide.
Back to the bugs. Inevitably, no matter what amount of thorough testing we've done before an initial product release, customers will find more bugs because it's hundreds and thousands more eyes and ears using the machine. Everyone uses the instrument differently so it's impossible to test for every use case before we ship. So, we always follow the initial release with one to two quick updates. We fix the new bugs that have been discovered and usually incorporate some easy to implement customer feature requests. At this stage in the very early lifecycle of the instrument, 95% percent of all bugs that have been found have generally been fixed. If a 1.0 OS customer updates to this newer OS version, they're usually completely satisfied. We'll call this is stage two.
We have a lot of concurrent instrument development and ongoing instrument maintenance happening, so it becomes a balancing act. Once we pass the initial release and subsequent update stages, the instrument is stable and reasonably mature. In this third stage, the instrument enters the "established" part of its lifecycle.
This means we continue to gather verified bug reports and new feature requests, but because we're in a stable part of the lifecycle this instrument will not see another OS update for around another 6-12 months. This is what allows us to design new instruments. So, no updates every month or two unless an unless a critical bug is found. A critical bug would be both high-visibility and high-severity, meaning it's easy to find and it does something like causes the instrument to crash.
Also the bug reports and feature requests slow down here. No matter how important any individual considers a bug to their personal workflow, once an instrument reaches this third stage there won't be another fix for quite some time. However, I can say with much certainty that does not mean it's the end of the line for OS development of an instrument.
From my perspective it's this third stage that is most frustrating for users because it's the part where you start thinking "it's so close, if only it had this, this, and that!" and then it's another 6-12 months before you see another update. This is also where users can start confusing "feature request" with "bug", because it's easy to justify something that doesn't work exactly as you expect as a bug. We are very deliberate in our design decisions, and we will gladly describe what the intended operation is. This also means no matter how much someone thinks "my way is much easier/better/the best way of operation for sure", that's a workflow debate and it's not a bug. Of course I'm not saying bugs don't exist, but this is a debate that happens often and people don't like being told we're not doing it their way even if they think it's better.
The fourth stage of the OS lifecycle happens at roughly 3 years after release. As an example, the Prophet 12 is entering this stage now. We've taken the time to, and managed to include some powerful new features even though the product is mature, along with fixing most every bug customers have reported. The P12 does what it does, and it does it well. It's stable, and feature-rich. We'll continue to sell this synth for a long time.
This instrument is now to the point where unless a critical bug arises, we probably won't see any more updates. There may be some very minor bugs that are uncovered along the way, but there's also a chance those may not ever get fixed, especially if there's a workaround or it's purely cosmetic. The amount of development resources required to properly test a new OS version for release are significant, even for a small change. For example, something like an incorrect character display on the fourth page of the oscillator section that doesn't affect operation is not going to warrant a new OS at this stage. That would be low severity and low visibility. Although we strive for it, there's no software that is 100% bug-free. If anyone has software development experience they will verify this.
Wrapping this back around to the Pro 2, this is my favorite instrument we make. It is not yet two years old; we started shipping it in August of 2014. That means it's gotten some initial updates and it works very well. It's in the third OS stage based on the definitions above. Is it complete? No. I'll be the first person to admit that, at least not in my mind. It has so much potential! Does it satisfy everyone? Of course not, but which instrument does? There are a lot of features and bugs I'd love to see implemented or fixed, respectively.
Does the Pro 2 satisfy the majority of users? Most definitely, and that's important to recognize. Because while there are a handful of users cursing the current state of the OS, there are many, many other people enjoying the synth and making music. Again, this is not a justification for "never fixing anything", nor is it a remark that nobody on the forums actually makes music because I know that's not true. It's just a point of reference which is easy for me to see because I can publicly see who says what online and I can also see all of our support requests. I'll add this goes for all instruments, not just the Pro 2.
Fortunately for us (myself and you guys), we're still due a couple OS updates based on the OS timeline. If the last OS update you guys are citing was "over 7 months ago" then we're right on schedule. It *is* on our radar, and we do intend to update this instrument again. And yes, it will be in the coming months.
Again, I can't compare this instrument or any other instrument of ours to the Tempest. If you look at the history of our products, nothing else has had a similar development cycle, nor was it released in a similar state. For those of you following the Tempest, it will also be seeing an update in the coming months, as it's still in need of some work and it's about time to dive back into that one as well. I think the last update for that was a little over a year ago, which means its due, purely based on the timelines I spoke of above. I can unconditionally assure you it has nothing to do with any online community uproar.
I'm jumping around a little here, but I want to return to the balancing act of concurrent development and maintenance. This is the part where I've often heard suggestions of "open-source the code" or "hire more developers". That simply isn't going to happen. Large parts of our OS are built on the same codebase for every instrument. We're not going to give away that intellectual property. Why don't we higher more developers then? Well, though we're very visible in the synth world we're an intentionally small company. There are only 12 of us including Dave, and that's more than double the number of employees from when I started.
We have a small office, and this is a private business owned and operated by Dave Smith. He has a lot of fun doing what he does, and the business is run the way he wants. We run at high efficiency and high agility. The more people we hire, the less agile we become, the more oversight and management is needed, the more overhead we have, and the more instruments we need to sell to meet our operating expenses. Dave isn't interested in managing a large company nor ramping up advertising to sell more products, he's most interested in building innovative music machines and would rather put his energy into that aspect of the business. In short, he's comfortable with where things are at.
What does that mean for the user? Essentially, it means it's best to appreciate the instrument for what it is now, rather than what it can become, knowing that based on my outline we haven't ceased development. If and when that happens, we'll be upfront about it and make a public announcement.
The large majority of feedback we receive on our instruments is overwhelmingly positive. There are a small number of power users that are continually frustrated by the pace of the OS development for any given instrument, myself included. But, entirely based on statistics, we really are in the minority.
The best advice I can give is to be patient, and prolifically share any beta OS we post so it reaches as many users as possible, which in turn assures the most possible bugs found during the active development stage. I say be patient because if you've taken the time to report a bug and you've figured out how to reliably reproduce it but it's been a couple months, we haven't forgotten. But, now you know our timeline and it's best to count months rather than days or weeks. If you're ever curious where we're at, feel free to ask. The best way to get an immediate response to any question is to email our dedicated Technical Support channel.
If there's anything else I can answer for you that I haven't covered here, let me know. All I ask is that you keep it constructive, polite, and on-topic.
72 Replies
42041 Views