Menu
What's new
By:
Filters

The risk of using Spitfire plugin on a commercial project

JohnG said:
It is wildly overblown because:

1. The OP had a computer problem -- Computer problems cause -- problems. It could have been another library so why pick on any one developer? It wasn't caused by Spitfire or anything to do with the library, it was the OP's own issue with (presumably) his boot drive or the drive where the library was stored.

2. Limited Downtime -- Compared with, say, a destroyed iLok or a failed disk drive that involves a long re-download, even a three-day process to restore a missing library is no worse than you might find with any library; and

3. Professional composers always will find a workaround. If they don't (and they should) have a mirrored drive ready to go to restore anything lost, they will have an alternative library that will get the job done, or use a different sound.

It is overblown to imply that this would have been a catastrophe for anyone with that kind of time pressure. People with that kind of gig have backups, more backups, and extra backups so they can always keep going.
Click to expand...
Not trying to argue a ton here because obviously your mind is made up. But the title of the post was " The risk of using Spitfire plugin on a commercial project " and you said the title was wildly overblown and have now listed everything thats not to do with the title. The title didnt say that using spitfire would be catastrophic, merely that there is a risk involved in using a library by a developer that has a bad DRM system. Also i just want to point out that one, SSD's in any kind of raid can be problematic when we are using libraries.

Also it's kind of funny that you keep mentioning having backups, more backups, and extra backups. You do realize that by having multiple backups that you'll have used up all your resets and unless you have SSD backups which im sure nobody here uses SSD's as backup drives. That moving the library from your backup back to your SSD would most likely incur a Reset, and if you have used all your resets on backups then you have to go through support anyway because you're now back to square one with the issue. I just don't see why you feel the need to defend a company's bad DRM practices, and at the same time victim blame a fellow user on this forum.
 
drews said:
Not trying to argue a ton here because obviously your mind is made up. But the title of the post was " The risk of using Spitfire plugin on a commercial project "
Click to expand...

Fair enough, but why pick on SF? One could post a thread titled "the risk of using a computer to meet a looming deadline". I don't know what's worse....using up the rests (which I have never done once over the years), or having to do a system recovery right in the middle of a project.
 
Jeremy Spencer said:
Fair enough, but why pick on SF? One could post a thread titled "the risk of using a computer to meet a looming deadline". I don't know what's worse....using up the rests (which I have never done once over the years), or having to do a system recovery right in the middle of a project.
Click to expand...

Because SF is the only one that i know of, actually in pretty much all of software that uses a DRM system that isn't attached to any hardware or account ID, and also requires you to contact the company to essentially deactivate old activations. Like ilok isnt amazing, but theres multiple ways to have access to your license. NI isnt amazing with the Native Access, but their DRM doesn't actually have teeth with the license limits, so in the end it doesn't hurt the consumer.

It wouldn't be any issue at all if SF had a setting like 95% of all other software to be able to deactivate all prior devices without going through support. Think about how windows handles DRM, it's tied to hardware ID and when you enter an already used serial, you have the option to deactivate the previous one. Also the fact that a redownload, repair, or moving a library counts towards your limit is absolutely anti consumer and insane
 
drews said:
But the title of the post was " The risk of using Spitfire plugin on a commercial project "
Click to expand...

I work full time at this and am on a series -- a "commercial project" -- using tons of Spitfire day in, day out. I flatly disagree with the OP about the 'risk' being any worse with Spitfire. In fact, it's far less than would be the case if you accidentally smash an iLok because the delay with Spitfire would be considerably less.

drews said:
I just don't see why you feel the need to defend a company's bad DRM practices, and at the same time victim blame a fellow user on this forum.
Click to expand...

He's a victim of a computer failure, not Spitfire. Computers are fallible. Professionals with deadlines (to which he alludes) are not going to be stuck, unable to work, because one library is inaccessible for a few days. You just use something else and keep going.

Moreover, I don't agree that the DRM policies at Spitfire are "bad." I have had 10x the troubles with Native Access that I've had with Spitfire.

Nobody likes DRM. It can take hours to navigate through Microsoft, plus emails, receipts etc. if your boot drive blows up or you have to replace a motherboard.

If DRM is effective (iLok, East West), there is always inconvenience or extra demand on the CPU, but the companies with DRM that works stay in business. It's like complaining about the weather.
 
This isn't a black and white issue. You can be a victim of a computer failure AND bad DRM system. Lets use an example where his library got corrupted using ilok. All he has to do is redownload the library and it works. Lets use an example of Davinci resolve where they give you 2 licenses. If both computers fail and you have to get a new one, it gives you a message that says something like "You've reached the maximum activation limit, would you like to deactivate a device?" The problem with spitfire is that last option is you have to email support, which is inherently problematic. Why can't they make it an automatic system when almost every other company has no issues doing it?

www.native-instruments.com

Home - Community

Join the NATIVE INSTRUMENTS community and learn more about your products with producers, creators and Djs from around the world.
www.native-instruments.com www.native-instruments.com

Check out that thread on how NI and heavyocity handle it. They dont require you to uninstall the previous, its merely a legal thing.
 
FYI, Spitfire customer service got back to me and reset the download limit for my BBCSO.
The response took two days...

I was able to reset and re-download the library, after which I got the red warning mark in the SF player. I had to perform "repair"... several times. Eventually, I deleted the Patches and Presets folders, after which the "repair" finally worked.
The whole process felt incredibly random. Even after the final, successful attempt, the SF app would show red exclamation marks, when in fact it just needed to be restarted one more time.
I am not sure, how much all of this used up my recharged "reset" limit. Am I maxed out again?

Some of you wondered, how I used my previous "resets" in the first place. Looking back, it was only on two occasions. Once, I wanted to move the library to another hard drive. The second time was simply updating my BBCSO to the latest version, which completely messed up the whole library and again required multiple repairs/resets.

Even if you follow the rule of not changing anything in the system on a project, there are times you may have to, either because of a technical issue or due to a creative need. I said, I noticed the problem after recovering my system to an earlier point via TimeMachine, but I don't actually "know" that this was the case. For me, TimeMachine has always been the safest tool to roll back, if I thought I'd done something I shouldn't have. Could it have interfered with Spitfire copy protection? Maybe..., but should it be able to?
 
Last edited:
JohnG said:
In fact, it's far less than would be the case if you accidentally smash an iLok because the delay with Spitfire would be considerably less.
Click to expand...
About that, is that something that regularly happens to people?
My iLok is plugged into my USB Hub, and gets unplugged once a year when I change my setup.
Not that worried to smash it.
Or do you mean software issues?

The 'risk' using the spitifre player is that, if you have to move a library mid project, you might end up resetting and repairing it until you need to contact support.
I had the exact same issue with EWC, moved it to another hard drive, stopped working, contacted support. Simply shouldn't be the case, and it isn't with any other library I know of.
 
Sugar Free said:
FYI, Spitfire customer service got back to me and reset the download limit for my BBCSO.
The response took two days...

I was able to reset and re-download the library, after which I got the red warning mark in the SF player. I had to perform "repair"... several times. Eventually, I deleted the Patches and Presets folders, after which the "repair" finally worked.
The whole process felt incredibly random. Even after the final, successful attempt, the SF app would show red exclamation marks, when in fact it just needed to be restarted one more time.
I am not sure, how much all of this used up my recharged "reset" limit. Am I maxed out again?

Some of you wondered, how I used my previous "resets" in the first place. Looking back, it was only on two occasions. Once, I wanted to move the library to another hard drive. The second time was simply updating my BBCSO to the latest version, which completely messed up the whole library and again required multiple repairs/resets.

Even if you follow the rule of not changing anything in the system on a project, there are times you may have to, either because of a technical issue or due to a creative need. I said, I noticed the problem after recovering my system to an earlier point via TimeMachine, but I don't actually "know" that this was the case. For me, TimeMachine has always been the safest tool to roll back, if I thought I'd done something I shouldn't have. Could it have interfered with Spitfire copy protection? Maybe..., but should it be able to?
Click to expand...
This happened to me also, and under the same circumstances except that I was on a Windows 10 computer. It took them 5 days to get back to me and give me more resets. When I asked how many resets I had they ignored that question. I asked if I would have to go through this again if I installed a new drive and they said it shouldn't be a problem. I don't have much confidence in that statement.
 
kimgaboury said:
Basically, you CAN’T move the location of the samples without being dependant on them to do a reset, just to be able to use the libraries using their plugin. I had to do a lot of changes with my SSD’s and workflow over the last year, and having to write them everytime, and wait a few days for a reply, is extremely annoying and even arrogant on their part. I hate the way they have implemented this.
Click to expand...
Kim!!!! Allô!!!
 
All DRM is dependent on remote availability, internet or human, aside from the USB keys (and even those require it initially). If they allowed you to deauthorize a prior computer, and you had that computer off the internet, that computer would never know it was deauthorized. Now you could sell it someone else, duplicate the drives, forge the machine ids.
 
Sugar Free said:
I said, I noticed the problem after recovering my system to an earlier point via TimeMachine, but I don't actually "know" that this was the case. For me, TimeMachine has always been the safest tool to roll back, if I thought I'd done something I shouldn't have.
Click to expand...
@Sugar Free: just out of curiosity - why did you have to do this?
 
My iLok for Cubase gave me all sorts of bother. Final straw was when it took Cubase Support around 4 weeks to respond to my support ticket to then have them assume that because it had taken them 4 weeks to respond that my issue would surely be resolved by now (without their support) and that they where closing the ticket and if it was still a problem I was to then raise another ticket! Needless to say the issue was still unresolved when they closed the ticket. I switched to Logic after that experience.
 
You must log in or register to reply here.
Top Bottom