What's new

Spitfire bringing out libraries fast but ignoring problems in the ones that are already out

I think it is pretty much in universal agreement now that the single tree mic for the Core was a terrible idea. It is near impossible to position the instrument in a mix. The price is good and I have no issues with only 1 mic. But it should be a MIXED mic. Would it really be that much trouble to have an update and change the single mic to a MIXED mic instead of the TREE mic?
Honestly, it's not that much of a difference. Have a listen, the first one is Core. The second is Pro with Tree2, Close1 and ambient. I turned it down a few db to match dynamics, other than that I didn't touch it.
 

Attachments

  • oboedemo.mp3
    1.6 MB · Views: 118
Last edited:
What too often occurs on forums is EVERYBODY is an authority and expected to be treated like
one. The reality is every developer who has been in business for a length of time knows what they tried to accomplish and thinks they know how well or poorly they actually did.

Eventually the amount of sales or lack of them tells them if they were correct, not a bunch of "experts" posting on a forum.

That is actually very treacherous ground.
The assumption that a quiet customer is a happy customer can be very misleading.

With sound libraries we often own a license to a great number of them. Many of those are being used only occasionally and rarely to their full potential. Hence we might not run into a lot of bugs or issues simply because we don't use them enough. Someone else however, in their particular workflow, is using that library much more intensely and WILL run into whatever bugs might be in there.
In this sense maybe none of my compositions would ever happen to include the note B5 of the muted 'Nose-blowing Alien Trumpet'. That note might be horribly out of tune, be panned wrong or full of audible artifacts, but I will never know it. Someone else however will. They may or may not report the bug, and in the end there is only a few reports reaching the developer. Still, the bug may be real and may pose a definite problem to those who use the library intensely enough. Those are then the bunch of "experts" who might not get a satisfying reply from the developer's support team and then take it to a public forum where, granted, the display of frustration may sometimes look out of proportion. But they may have a valid point and may not represent as isolated of an issue as it may seem.
 
As a business, you need a quite strong incentive to spend time on something that won’t bring in money, instead of spending it on something that will. Individual or small group-complaints just doesn’t make much sense from a developer perspective unless many people are complaining on the same thing (and by many, I mean many in the grand scheme of things).

If developers fixed everything people wanted them to, they would both risk upsetting other users that were already happy with it (as generally, changing things in existing products that people are used to cause uproar), and by doing that also loose time and money that could be better invested elsewhere (both from a business perspective and the perspective of the overall user base).

What controls these decisions in the end are partly money of course, but also the developers own overall future vision for their entire product catalog (which we as consumers often aren’t even aware of).
 
SCS’s performance legatos are fixed and working well as of the current latest version, as best as I can tell.
I second this ; the last update fixed issues.
That said, for runs, Perf legato is hit and miss. Sometimes wonderful, sometimes horrible. What I miss the most is rebowing.
 
Didn't they just add 60gb of free, new samples to Hans Zimmer Strings?

I'm no spitfire defender but the problem when people talk about fixing libraries is they tend to mean 3 different things...

Fixing actual bugs in programming & glitched samples (which imo is the only legit reason to use the "fix it!" language)

Requesting what is in practice an expansion of the library ("Fixing" HZS to add more string shorts)

Or requesting what is in practice a re-do of the library ("Fixing" the dynamics in BBCSO solo horn).

People should have realistic expectations about what can be fixed. If it requires re booking the hall, re booking the musicians, setting up all the mics and recording & editing gigabytes more of samples, maybe it's not a very realistic fix to expect.

Your issue with SSTW's single mic isn't even any of these, you just want to have all the mics in a mixed format; Spitfire were pretty clear in their product descriptions about the difference between these two products.

Tons of bugs in SStW which deserve "Fixing" imo. Spitfire is aware of these. But somehow their product release teams work a lot faster than the QA/ QC/ Bug fix teams....
 
If developers fixed everything people wanted them to, they would both risk upsetting other users that were already happy with it (as generally, changing things in existing products that people are used to cause uproar)
The following isnt particularly about Spitfire, but noisy samples, exaggerated portamento, sloppy timing or inconsistent attacks are all examples of issues all of us should be happy with being fixed.
The main thing I want from VI companies after a purchase are a list of known issues and an email when a new version is out, but many of them tend to not share such info, but instead send large amounts of repeated emails about sales and new products.
 
Last edited:
Tons of bugs in SStW which deserve "Fixing" imo. Spitfire is aware of these. But somehow their product release teams work a lot faster than the QA/ QC/ Bug fix teams....

Indeed they do. As I said on another recent thread, Sable-now-SCS still has 8-year-old real shockers in it that need a couple of weeks and a copy of RX to fix, but Spitfire support told me its not a priority for them.

So there you have it - if QC is important to you, its always useful to know when it isn't important to any particular company, so it can inform your purchasing decisions. But with a commercial head on, you can see their point of view as folks keep on buying stuff in vast quantities, thrilled with the very prospect of every shiny new release. The Spitfires and 8dios of the world have their place, clearly.
 
The quick answer to why there are so many releases is that Spitfire have a staff count of 50+, 3 floors of London office real estate to pay for and all the rest. That'll drive the need for a continued release schedule like nothing else.

I've never ran a company with a large employee count, but I know folks who have who all say taking responsibility for a large number of people (and their bills) puts the fear of God into you. No wonder the focus is on making new products to keep the cashflow going.

I'm sure if a bunch of users en-masse had the same complaint, Spirfire would fix it. The initial release of BBCSO is a great example of developer response. But I assume the occasional email and forum complaint (sensibly) isn't enough to allocate expensive developer resources away from new products.

There's also that thorny subject of whether Spitfire considers some of these issues to be "bugs" in the first place. But I'll leave that for others to debate. ;)
 
Last edited:
By continuing to release more products means they can continue to invest in maintaining their legacy products. I’d also imagine they have different teams working on their various product lines so new product introductions wouldn’t necessarily impact legacy product maintenance.
 
One thing too bad : instead of re-balance their orchestral line (SSO), they prefer release a new orchestra advertised as balanced (BBCSO).
 
One thing too bad : instead of re-balance their orchestral line (SSO), they prefer release a new orchestra advertised as balanced (BBCSO).

Updates are nice of course, but there are diminishing returns for tinkering with old libraries. While BBCSO is something genuinely new. Its sound and cohesion is build into the concept and the engineering, probably drawing on all the experience from the SSO. And it achieves something entirely new, that you're not going to get by rebalancing SSO.


Again, updates are nice. But so is pressing forward and discovering new things.
 
One thing too bad : instead of re-balance their orchestral line (SSO), they prefer release a new orchestra advertised as balanced (BBCSO).

One would think that the time for bigger possible updates, like re-balancing things, is when the old Kontakt library is brought to the new player. That would seem sensible.
 
I'm pretty sure the SSO line will receive a face lift this year though.
Absolutely agree. Also, I'll gaze into my (grubby) crystal ball for this one and lay down an early marker:

I'm betting more than just a facelift for the SSO. Existing users would (perhaps rightly) expect a free update and it wouldn't open the product to a new market = what's the point?

So, either a price drop or...

.. the new versions will include all the mics from the pro versions as standard. Masse will be dispensed with. Same price points. This way, the new versions appeal to prospective buyers even more and existing SSO users have a nice (chargeable) upgrade path. They'd also be a clear price contrast between the SSO and BBCSO.

But like I said, my crystal ball is covered with fingerprints and needs a good clean. ;)
 
Last edited:
I posted my thoughts on this matter in another thread, but as it fits perfectly here, I copy and paste:

--------

I really start to understand now the feeling that many of you have shared here on the forum: Instead of taking the time and fixing at least some of the glaring issues in their very current lineup (yes BBCSO I am looking at you), they seem to move on and push out new products in an ever accelerating manner.

EDIT: this does not make me less excited about the new Albion per se. I love Spitfire, have and use a lot of their their libraries and find many of them to be excellent and the best of their kind. But this point bugs me. I kind of understand the "shell out more products, sell more, get bigger, and growth is necessary in order to survive in a very competitive market" argument. But I believe it's a false dichotomy (that kind of reflects the modern times and associated short-term oriented thinking).

a) simply from a musicians and customers perspective, and

b) also for their own welfare as a company in the long term. Quality (and therefore justified higher price points) trumps quantity and a growing bunch of users of older products with partially unfixed issues that become more and more unsatisfied because of this. Sustainability and an enthusiastic fellowship of customers are, in my view, a more viable long term strategy, also and especially from an economical perspective. History and logic have clearly proven that in my opinion.

---------

I wrote Spitfire some of my concerns regarding some of the in my view most important issues with BBCSO. And today I got a lengthy response. At least, they are listening, and it seems that they are incorporating at least some of our feedback. I appreciate that very much.
 
That is actually very treacherous ground.
The assumption that a quiet customer is a happy customer can be very misleading.

With sound libraries we often own a license to a great number of them. Many of those are being used only occasionally and rarely to their full potential. Hence we might not run into a lot of bugs or issues simply because we don't use them enough. Someone else however, in their particular workflow, is using that library much more intensely and WILL run into whatever bugs might be in there.
In this sense maybe none of my compositions would ever happen to include the note B5 of the muted 'Nose-blowing Alien Trumpet'. That note might be horribly out of tune, be panned wrong or full of audible artifacts, but I will never know it. Someone else however will. They may or may not report the bug, and in the end there is only a few reports reaching the developer. Still, the bug may be real and may pose a definite problem to those who use the library intensely enough. Those are then the bunch of "experts" who might not get a satisfying reply from the developer's support team and then take it to a public forum where, granted, the display of frustration may sometimes look out of proportion. But they may have a valid point and may not represent as isolated of an issue as it may seem.

Yep, under-reporting of bugs is a serious problem for developers on this forum.

Thanks, I needed a good laugh.
 
Yep, under-reporting of bugs is a serious problem for developers on this forum.

Thanks, I needed a good laugh.
Whilst this did make me chuckle, Wunderhorn makes a couple of good points. I've abandoned products before due to bugs but never once reported them or publicly complained. I just...moved on.

But yep, the whole "calling developers to account" culture on public forums isn't something I'm a fan of.
 
Top Bottom