BFD3 wiped out its settings in a project because it was opened & saved unauthorized, unbeknownst to me

I want to scream and yell and smash things.

I opened a project to write audio tracks for an abandoned plugin that doesn’t work in Mac OS Monterey (Tassman). I did not check that the BFD portions of the song were playing, because it was working FINE for the hours prior on other projects, and this is a very long piece of music with the drums at the end.

I saved my changes, moved the project over to my newer iMac (the reason I have to leave Tassman behind)…

…only to find BFD is silent. The lack of BFD3 being authorized resulted in it saving the project with NOTHING, NADA, ZERO in BFD. I have NO EFFING IDEA what the drums were and I don’t even know where to go look, since I moved everything to BFD3. It kept the name of the settings in the preset name area at the top of the UI, from when I ported the settings from BFD2, but none of the ACTUAL settings. This is an EGREGIOUS BUG caused by EGREGIOUS licensing tech.

Your licensing tech is goddamned GARBAGE and I am so disgusted with the MONTHS of SUFFERING that this GARBAGE product has caused me due to converting my projects from BFD2 to BFD3, the preset loading bugs that made that process take three times longer, and now this APPALLING SCREWUP with the licensing killing the plugin’s settings!!!

I cannot imagine EVER spending money on inMusic or BFD, ever ever again. At some point, I will have to write all my BFD tracks to audio and abandon the product entirely. NO ONE should EVER tolerate this number of problems in a product from ANY company. inMusic’s insistence on using this effing BS licensing scheme is a constant form of abuse on their PAYING customers.

EDIT: If anyone gives a damn, I recovered the preset from an older version of the file I had in my Trash from when I moved the new project file to the newer iMac. There seems to be a bug in Mac OS networking that corrupts packages like Logic project files when replacing an old one with a new one across the network, so I started just having it do “Keep Both”, and then trashing the old copy and renaming the new one from “…2”. This was a lucky coincidence (that I had this old copy - though, yes, I do keep backups, and I didn’t even think about that in the moment, because I was FREAKING OUT), so I am still outraged. I am fairly sure that this didn’t occur to other projects earlier this morning/last night, but this could have been a MASSIVE LOSS for me in terms of ruining a very important song for me.

This is a DATA LOSS BUG.

1 Like

Sorry to hear about your frustrations. I was similarly frustrated and decided to not give inMusic any more money (through BFD or other products of theirs).

I am still in the process of selling BFD. I had to go rock bottom on prices and even give some stuff away just to get some interest.

1 Like

I have BFD 3 and nearly all the expansions and groove packs, I’ve been waiting two years for Mac M1 compatibility. They keep on promising it but it never comes.
Just like Lexicon, iZotope etc. etc. the list goes on and on. I don’t believe a word they say any more.
All Inmusic (like all these ‘money people’ run conglomerates) want is your money and have no interest in producing professional tools. Instead all we get is broken toys and BDF 3 is just a toy and it’s well and truly broken !
Best spend your money on a real drum kit and time learning how to play it or make friends with a human drummer.
Software is great when works but it really gets in the way of making music. We were promised that computers would make our lives better and easier, ha, what lies !
We should all go back to reel to reel recorders. So🖕to Inmusic, stop wasting our time and money.

1 Like

The product has been this way since 2013. This isn’t new, and would’ve occurred with previous FXpansion-era builds as well. It’s not down to the licensing system, but rather it is down to the preset file format and how slots are propogated - authorizations are confirmed, and then the drum is loaded. If the authorization is not confirmed, the drum isn’t loaded. If the user then saves the project, they lose the drums in this way.

We know it isn’t ideal, we know it needs to change, but again, it isn’t new.

What should happen is that references to the drum are not discarded upon lack of authorization. This is a change we have on the cards, but I don’t know when.

It’s in beta as we speak. I was supposed to ship a new beta today, but our build server hasn’t yet delivered anything. Looks like it will be tomorrow now.

Hi LoRes and welcome to the forum.

I feel your frustration. I too am very sorry I spent so much money on BFD3 and expansion packs for a product that has turned out to be so flawed. I keep holding out hope that everything will get fixed within a reasonable amount of time. M1 compatibility would be a good start.

Check out the iZotope web site as they have updated almost everything to being M1 NATIVE compatible. Here’s a link to a page with info about Apple Silicon and the last 5 macOS versions:

The real culprit in all of this is Apple and they are known for abandoning old technology in favor of the new technology and every company does not have the R&D in place to keep up which is why some companies go under which is why Fxpansion got bought out. Some companies are one man operations and don’t have nearly the resources that bigger companies have. I love BFD. Don’t get it twisted If they go under I will still make music with another drum package. Meanwhile I’m stuck like Chuck and yes this has been painful for me as well as for everyone that makes tools for the composer we all at some point experience loss of some kind but how will you survive this process? The choice is up to you!!!

I can understand if BFD3 is not compatible with newer Mac or even PC systems because it is quite an old software product. What I don’t understand is why it was altered in its later years to make it more risky for its customers to use if opening a project on a computer that isn’t hooked up to the internet on a regular basis. This effectively puts the registered “owner” of the software product in the same category as the person who never bought it; neither of them can use it without first dealing with the company.

When I say “owner” of the software, I don’t want to get into a battle of legalistic semantics; that’s all nonsense because every thoughtful human being KNOWS what “owning” software means. It means that if I buy it — like I did BFD2 in 2008 — that it will still work on my old Windows 7 computer, even if I don’t fire up that machine for years at a time. And that is the case. I have BFD2 on a computer and countless other pieces of software that I “own” as long as the computer works and as long as I don’t try to upgrade something that makes it incompatible.

I think this is where InMusic got it really wrong. Whether or not we lose data to various working conditions, that can happen. But during that process, we should also not have to be fighting for our right to use the software we paid for. That, to me, is the continuing sore point with using BFD3.

Step 1: Company’s lack of trust in customers. Step 2: Company reacts to its fearful lack of trust by creating an automatic software shut down system for registered users. Step 3: Company shows indifference toward the problems it creates for its loyal, paying customers by stubbornly insisting on treating everyone from its chosen perspective of suspicion.

But I think talking about this is like trying to talk an addict out of their addiction. Not likely to happen.


I’ll take your word for it that it was like this all this time… but I’ve never had the authorization system screw me with it before the current system. I still blame that.

1 Like

with all due respect,

It’s … the licensing system

suffered the same in the early days of the relaunch despite being pretty good about best practices as there was no way to know when this would happen. there could be differences related to a specific OS/DAW, but can’t recall ever losing any active settings in the many years of using BFD prior to InMusic. and can’t think of any reasonable use case where a purchased/previously registered product would need to be authorized again while working on an active project.

1 Like

100000% it’s due to the preset format, and not inherent to the licensing system. This would have happened even in BFD2, back in 2008.

This needs fixing, but it needs fixing in the right area.

have no doubt you’re absolutely right from a product perspective, but from a user perspective it never used to be an issue. have no idea if there actually were authorization checks pre InMusic. they just never dumped existing settings when loading a project.

just my 2 cents.

1 Like

I think that would only happen with BFD2 if you moved, or deleted the Fxpansion authorization file, which wouldn’t be very likely.

Or upgraded your RAM, or OS major version, or GPU, or your Mac address changed. A whole host of things could make an auth file invalid back in the day, just as with any authorization mechanism.

I recognise the annoyance of the auth-system, but I’m trying to be clear that this issue isn’t new and isn’t specifically caused by anything to do with the authorization system. It’s caused by BFD3 itself being dumb and literally and deliberately clearing all of the references to the drums when no authorization can be found. There’s some nuance there I’m trying and probably failing to get at.


Fair enough. (20 characters)