What's new

Will you be buying Spitfire BBC piano?

Will you be buying Spitfire BBC piano?

  • Yes

    Votes: 54 12.9%
  • No

    Votes: 344 81.9%
  • I’ve already bought it and it’s great

    Votes: 18 4.3%
  • I’ve already bought it and wish I hadn’t

    Votes: 4 1.0%

  • Total voters
    420
TBH I don't know what position it's in, though - the video showed both in 'orchestra that has some piano playing in it' a la Bartok or Respighi, and 'orchestra with piano concertante' positions, so I don't know if this is meant to be a soloist, or meant to be the piano in the back adding texture to the low strings and winds.

The problem is that if the answer is that it doesn't matter which one it is, then it seems to imply that the library is unnecessary in a way, doesn't it? And if it does matter, then why isn't it immediately obvious which 'piano with orchestra' they're aiming for? You could just put in the copy with one sentence whether it's made to 'blend with the orchestra in passages' or 'stand out as the soloist' and it'd be perfectly clear.

Just one of several frustrating things for me about this release, but the one that's the most of a backheel own goal to my mind, where it sits and resonates and annoys me.
In the reveal video, Paul mentioned that it's recorded in the concerto position, in front of the orchestra.
 
I've said this before, (and I might be totally wrong) Spitfire Audio would be wise to adopt a more Orchestral Tools-oriented model at this point. Ie. release fewer, but more deeply sampled and better polished libraries.

Spitfire Audio has released an enormous amount of sample libraries over the last decade, putting out something nearly every single month of the year (or more). At some point there must be market saturation. Then you either have to lower prices or innovate - ie. raise the quality level/depth of the libraries, or invent some new technology, like the sample modeling in Aaron Venture's libraries. Also using 15-20 mic channels, while skimping on sampling depth, is rubbing people the wrong way.

To put it into perspective. I've bought 5 Originals pianos from Spitfire, but only 1 of them has a consistent velocity response across all the octaves, which should be a given. The last one (Intimate Grand Piano) has poorly edited attacks on notes in the middle octave, with the sustain pedal down (sounds like sloppy playing). I've reported this twice, and a year later nothing's done. With no demo version or money back-option, I'm hesitant to spend money on another SA piano at this point.

To be fair, SA has put out many of the best sample libraries on the market: Appassionata Strings, Symphonic Orchestra line, Chamber Strings, their orchestral/classical percussion libraries are great, Abbey Road 1 is a mixed bag, but mostly very good, Mrs. Mills and Intimate Strings are amazing quality and value for 29 bucks etc. However, I've been burnt on too many undercooked libraries, with no released patches or fixes.
 
Last edited:
I've said this before, (and I might be totally wrong) Spitfire Audio would be wise to adopt a more Orchestral Tools-oriented model at this point. Ie. release fewer, but more deeply sampled and better polished libraries.

Spitfire Audio has released an enormous amount of sample libraries over the last decade, putting out something nearly every single month of the year (or more). At some point there must be market saturation. Then you either have to lower prices or innovate - ie. raise the quality level/depth of the libraries, or invent some new technology, like the sample modeling in Aaron Venture's libraries. Also using 15-20 mic channels, while skimping on sampling depth, is rubbing people the wrong way.

To put it into perspective. I've bought 5 Originals pianos from Spitfire, but only 1 of them has a consistent velocity response across all the octaves, which should be a given. The last one (Intimate Grand Piano) has poorly edited attacks on notes in the middle octave, with the sustain pedal down (sounds like sloppy playing). I've reported this twice, and a year later nothing's done. With no demo version or money back-option, I'm hesitant to spend money on another SA piano at this point.

To be fair, SA has put out many of the best sample libraries on the market: Appassionata Strings, Symphonic Orchestra line, Chamber Strings, their orchestral/classical percussion libraries are great, Abbey Road 1 is a mixed bag, but mostly very good, Mrs. Mills is a brilliant piano for 29 bucks etc. However, I've been burnt on too many undercooked libraries, with no released patches or fixes.
I don't think the production rate will drop, because a nice idea has simply become a business. But I still have the feeling that they are making less hype about their releases, which I think is a very good sign.

I'm not a professional, but many forum readers complain that there are obvious bugs in many of their long-released products, and releasing new products gives the impression to some users that product maintenance is secondary.

If the opinion of some users here is corret and there are obvious and submitted bugs in older products, I wonder how the employees are doing. As a developer, I wouldn't be happy if I simply can't keep up with open bugs from old projects, because you either have to develop new products or new bugs are added by releasing new products.

Conversely, a reduction in the production rate would also affect the financial income (cat bites its own tail).

And I can understand every user who gets upset about the choice of words in marketing. When a company uses the wording "broadcasting standard" I expect it to be correlated with the quality of the product and yes, no major bugs either.

Personally, I think SFA is a great company and without them we probably wouldn't be here where we are now. but I think the hype around products much too high. I would like to have less, but really carefully selected and really polished products.
 
Last edited:
Has anyone got a reply from spitfire support yet?
Yes - a bit of blah blah blah on the installation process mess, including more incorrect information on the errors that had been generated (sigh)

No mention of the CC change but I'd flagged some other NEW random bug and this was described as: "as the developers intended" with the usual gobbledegook reasoning.

ticket closed.

(anyway, off topic for this thread probably!)
 
Expecting this to be a free update to BBCSO would be too much, I have no issue with paying extra for such a significant additional instrument. But on the other hand there has been so much talk of "adding" a piano to BBC for so long that offering only a temporary(!) 30% off to existing owners is pretty insulting. Especially at such a steep starting price for hardly the most detailed piano. As a BBCSOPro owner with really only one other significant general purpose piano library in my collection (CinePiano) I'm pretty much the target audience for this, and I couldn't justify it for more than like $80. If anything it inspires me to just pick up Cinematic Studio's piano, which is basically positioning itself the same way, seems well enough regarded and only costs $69
 
Expecting this to be a free update to BBCSO would be too much, I have no issue with paying extra for such a significant additional instrument. But on the other hand there has been so much talk of "adding" a piano to BBC for so long that offering only a temporary(!) 30% off to existing owners is pretty insulting. Especially at such a steep starting price for hardly the most detailed piano. As a BBCSOPro owner with really only one other significant general purpose piano library in my collection (CinePiano) I'm pretty much the target audience for this, and I couldn't justify it for more than like $80. If anything it inspires me to just pick up Cinematic Studio's piano, which is basically positioning itself the same way, seems well enough regarded and only costs $69
I was given their piano for free when I finished buying all the Cinematic Studio Series product range. Like you I have BBCSO Pro but I won't be buying that piano. UPDATE: For a limited period OT gave Berlin Orchestra Berklee for free to owners of the whole Berlin series of which I was a lucky one.
 
Last edited:
Decided to stop buying Spitfire products after they ostracised Christian Henson from his own company. Great products, expensive, no demos and no resale.
I stopped after BBCSO Pro as imo there are many comparable developers these days. The way the Henson departure was handled was very strange I agree.
 
I'm not a professional, but many forum readers complain that there are obvious bugs in many of their long-released products, and releasing new products gives the impression to some users that product maintenance is secondary.

If the opinion of some users here is corret and there are obvious and submitted bugs in older products, I wonder how the employees are doing. As a developer, I wouldn't be happy if I simply can't keep up with open bugs from old projects, because you either have to develop new products or new bugs are added by releasing new products.

Conversely, a reduction in the production rate would also affect the financial income (cat bites its own tail).
It's interesting reading the comments and speculation about what is going on with SA. For me music making is a hobby, by profession I am a software development manager for a global company looking after devs teams across 3 continents. While I've never worked for a sample/plug-in development company I have worked for a large design/build/media agency and I think that has a lot in common.

So if I were to speculate on what is happening based on what I see:

- SA has grown rapidly. It wasn't that long ago that they were a small team/company of folks who were passionate about music and quality samples and made what they wanted for themselves. Now they employ a 100 or so folks and have a large (and growing) product catalog. Quick growth is always a challenge because the folks that started the business are likely very good at what they did (make the products) and now have to learn how to run a growing business. They are new to these management roles and don't always make the best decisions that experience might lead someone else towards. You also have to hire a lot of folks quickly, ending up with a workforce with a high new-to-experienced employee ratio, leading to a lot of effort into training and learning the business (in every function).

- SA started out developing sample libraries that ran on Kontakt. They did not have to worry about developing and supporting the plugin software itself. If they had stayed with Kontakt the size of their product based would still mean a massive amount of work to fix bugs and issues in the libraries alone.

- But they didn't instead jumped on the industry trend of developing and launching their own plug-in platform. Now they are a software house and a sample library developer.

- So not only do they have their vast catalogue of sample libraries to maintain they also need to maintain the software they run on. Due to the nature of our industry they have to develop and support this software on multiple computer platforms (PC and Mac), operation system versions, plug-in versions (AU, VST etc.), DAWs and DAW versions. In every combination possible. That is a large testing surface.

- If they are a wise software development house then they will have a single code base for all of their plug-ins. From what I've seen I'm not sure this is the case. I suspect they have multiple versions of their plug-in for each library and this will lead to an ever growing support nightmare the more products they produce. EW have the right idea if you are producing your own plug-in - have a single version that all of your libraries use.

- They probably are using a lot on automated unit testing of their code, which is certainly a good thing, but given the size of their testing surface they may be relying on it too much at the expense of hands-on functional QA. This means that usability bugs (such as this CC mapping issue) are more likely.

Of course the more products they launch the harder this all gets, and future revenue needed to support the size of this growing business means that they have to develop new libraries. So I wonder how much pressure the sales and marketing teams are putting on development to get stuff out by a certain date, and I wonder how much the dev teams are struggling to do this at the right quality with the constraints of recruitment, training, tech-debt, testing surfaces and multiple codebases plaguing them.

Wayne
 
- But they didn't instead jumped on the industry trend of developing and launching their own plug-in platform. Now they are a software house and a sample library developer.
In some sense, they're a software company first, sample company second: if the software doesn't work, the quality of the samples is irrelevant.

Due to the nature of our industry they have to develop and support this software on multiple computer platforms (PC and Mac), operation system versions, plug-in versions (AU, VST etc.), DAWs and DAW versions. In every combination possible. That is a large testing surface.
It shouldn't be that bad in practice: the point of the VST and AU specs is to allow plugin developers to ignore specific DAWs, and there are frameworks that wrap up these details along with various other quirks. As long as the developer sticks to the framework's rules, they should be able to lean fairly heavily on the framework's own testing for the combinatorial stuff. This only works, though, if the plugin is regularly updated and released with the latest frameworks, since that's what will (hopefully!) ensure it stays compatible with the latest DAWs and OSes. If your build, test and deployment process is slow and cumbersome, that won't happen. I wondered if that was the issue re: MacOS Ventura compatibility. Ventura was released on Oct 2022, but SA still won't support plugins on that version.

If they are a wise software development house then they will have a single code base for all of their plug-ins. From what I've seen I'm not sure this is the case. I suspect they have multiple versions of their plug-in for each library
Definitely looks like the code was forked per-product, but what's certain is that updated builds of each product are released so rarely that they might as well be separate code-bases.

EW have the right idea if you are producing your own plug-in - have a single version that all of your libraries use.
Unfortunately, I think SA have painted themselves into a corner. Unless you start by ensuring all your products use the same parameters, controls, mappings, etc (and gracefully ignore those that don't apply) then you can never unify those plugins without breaking existing projects. They've been very casual about that this week, but that *should* be unacceptable to them. Assuming they come round to this idea, they'd essentially have to start again: release a new multi-product plugin with unified mappings for their whole catalogue, then start migrating products into it: that'd let users update their projects as/when they want a new feature, but without any uncommanded breaking updates.

I don't know first-hand, but sounds like SA did have standardised mappings across their Kontakt products?

They probably are using a lot on automated unit testing of their code, which is certainly a good thing, but given the size of their testing surface they may be relying on it too much at the expense of hands-on functional QA. This means that usability bugs (such as this CC mapping issue) are more likely.
This sounds optimistic to me. The most rudimentary smoke test I can think of for an audio plugin is to load it into an AU/VST test harness and make sure the info it gives to the host hasn't changed unexpectedly. The latest release would not have passed that test, and nor would the release that broke preset recall in 2021... and this is before we do anything crazy like testing inputs and outputs! The CC mapping issue is also eminently automatable: request "Mix 1" parameter value, send new value on MIDI CC#21, request "Mix 1" again and check it has new value. Done.

Of course the more products they launch the harder this all gets, and future revenue needed to support the size of this growing business means that they have to develop new libraries. So I wonder how much pressure the sales and marketing teams are putting on development to get stuff out by a certain date, and I wonder how much the dev teams are struggling to do this at the right quality with the constraints of recruitment, training, tech-debt, testing surfaces and multiple codebases plaguing them.
I'm turning the speculation knob up to 11, but I think the way you phrased this says a lot: "...pressure the sales and marketing teams are putting on development..." as opposed to senior management being the single source of pressure on -- or, ideally, a discussion of reasons with -- teams that are behind schedule. In many companies that have started their own software development, CEOs/Boards seem to just "let it happen", rather than paying attention to it as a critical part of their business. (Until it goes wrong, anyway, whereupon they may just go unproductively bonkers.) It can be miserable for the tech people, who generally like solving problems but can't get the direction, attention and resources they need just to avoid incidents.

[With apologies, Wayne, where I've said stuff you certainly already know: I just wanted to allow others to get the full stultifying experience of my frustrated ramblings :)]
 
This sounds optimistic to me. The most rudimentary smoke test I can think of for an audio plugin is to load it into an AU/VST test harness and make sure the info it gives to the host hasn't changed unexpectedly. The latest release would not have passed that test, and nor would the release that broke preset recall in 2021... and this is before we do anything crazy like testing inputs and outputs! The CC mapping issue is also eminently automatable: request "Mix 1" parameter value, send new value on MIDI CC#21, request "Mix 1" again and check it has new value. Done.

Such a test harness would be a good idea, and to would like to think that they have one. I confess though I was thinking of Unit Testing more at the code unit level and assuming that they then did integration and functional QA using the DAWs themselves. Hmm.

There's also the question of regression testing. As in, what regression testing did they do with BBCSO using the new plug-in version? It's obvious it didn't include loading an old project that contained CC automation and replaying it.

Do they even have a regression suite of projects across the DAWS for their plug-ins and libraries or do they test by creating new projects?

I'm turning the speculation knob up to 11, but I think the way you phrased this says a lot: "...pressure the sales and marketing teams are putting on development..." as opposed to senior management being the single source of pressure on -- or, ideally, a discussion of reasons with -- teams that are behind schedule. In many companies that have started their own software development, CEOs/Boards seem to just "let it happen", rather than paying attention to it as a critical part of their business. (Until it goes wrong, anyway, whereupon they may just go unproductively bonkers.) It can be miserable for the tech people, who generally like solving problems but can't get the direction, attention and resources they need just to avoid incidents.
I should have said pressure emanating from the sales and marketing team - whether it comes directly or via senior management. But you are right about the variable support (or pressure) that can come from the senior team, especially if that team is made up of non-technical folks who just don't understand software development (and don't care to) and the impact that can have on the software development team and product quality.

This is of course assuming that software development is (mostly) in-house rather than outsourced...

Wayne
 
Do they even have a regression suite of projects across the DAWS for their plug-ins and libraries or do they test by creating new projects?
Wasn't there some forum member not that long ago, who received a response from Support that boiled down to “our Windows test PC is broken at the moment, so we aren’t able to reproduce your issue”?

There was some amazement about there apparently / allegedly just being the one Windows PC. I may be remembering this wrongly and it may also be totally false.

Anyway. Thorough analysis you made there.
 
Wasn't there some forum member not that long ago, who received a response from Support that boiled down to “our Windows test PC is broken at the moment, so we aren’t able to reproduce your issue”?

There was some amazement about there apparently / allegedly just being the one Windows PC. I may be remembering this wrongly and it may also be totally false.
That’s concerning.
 
That’s concerning.
If it’s true…. But I do seem to remember I heard that from a reliable senior poster on here. Now I slightly regret bringing it up as I do not want to add anything “unfounded” to the echo chamber as it were. I will try to find my source. Which I should have done to begin with. Anyway…. Ignore until I can actually find something / someone that confirms this, for what it’s worth and apologies for mentioning it without quoting a reliable source.
 
assuming that they then did integration and functional QA using the DAWs themselves. [...] There's also the question of regression testing.
Very possibly; I was more thinking of a route back to agility. E.g. for a company with that many products, I think the only way to get agile again is to have testing fully automated. Ordinarily it'd be a pain to set-up, but the inital test suites could be automatically generated too incl. for GUIs and audio because their products are so similar. It wouldn't be hard to get to a point where they could learn of a serious bug in the morning and have a fix by the evening, confident that they've changed the bug and nothing else. (Armchair engineering is always so simple ;) )

[...] variable support (or pressure) that can come from the senior team, especially if that team is made up of non-technical folks who just don't understand software development (and don't care to)
Does this still happen? I only really know about more regulated industries, or companies seeking investment... in those cases, the directors would usually be considered rather negligent if they hadn't appointed someone tech-savvy to be on, or at least report to, the board.
 
Top Bottom