mDrummer: Can any of BFD, Superior Drummer, Addictive Drums, Kontakt libraries be ported over?

[Annabanna]

I've got terabytes of drum libraries. I would really like to be able to use them in the same ecosystem so I can stop having this insanely complicated system to Frankenstein together a kit. Not sure if that's possible, but if it is, mDrummer would seem to be the obvious choice.

I see the generic import capabilities for mDrummer, but wondering if anyone has specific insights into whether certain specific libraries can be ported over and used as multisamples within mDrummer or if the proprietary format they are in currently makes this impossible.

Specifically, I would like if possible to use within mDrummer libraries from:

1) Addictive Drums

2) Toontrack (Superior / EZ)

3) BFD

4) Kontakt (Mixosaurus plus at least a dozen others. Some are formal Kontakt libraries, and others are older .nki instruments.)

5) DPinga (I have found their standalone instruments to be among the most usable sounds for Latin percussion)

6) Ujam

7) I have a few assorted others too, so if anyone has specifics about what does or does not work for porting other libraries, interested in that info as well.





To be clear: I'm not concerned about mapping issues right now, or groove formats, or anything like that, but rather just whether it's possible to port over the multisamples to use in drum pad mode.

[whyterabbyt]

I'd assume most of these have kits in proprietary, closed, file formats. Certainly the ones Ive used do.

Also most will probably have licenses that preclude porting, reverse engineering or resampling of the kits.
Here's the BFD license for example.

The making of sample libraries in any form, commercial or otherwise, be they either single hits, drumloops, or fully mixed audio clips is strictly forbidden without express written agreement of FXpansion and its audio partners, and violations will be prosecuted to the full extent of international and local copyright law. The ownership of all the BFD3 audio material and associated MIDI performances is fully asserted by FXpansion and its audio partners. Please feel free to contact FXpansion for any clarification.

Toontrack have this

NO MODIFICATION. Except as set forth in Section 6 (Terms of Use), you may not modify or create derivative works in whole or in part based on any one of, or on any part of, a Product.

You can check the rest of the EULA's for yourself, Im sure. But expect a resounding consensus of 'no, f**k off or get sued' to be contained therein.
And the only way around that is to get explicit permission from the developer. Which you almost certainly wont get for most of these. Your main hope there is small third-party Kontakt developers.

I'd also expect Melda, if they're sane on legal matters, to avoid condoning this even slightly.

[Annabanna]

... You can check the rest of the EULA's for yourself, Im sure. But expect a resounding consensus of 'no, f**k off or get sued' to be contained therein....

A friend of mine builds his own MIDI drum kits for his own amusement. As a practical matter, he needs to use head units which were designed to be used with the kits with which they were sold.

Call him a criminal if you like. I find the notion unworthy of discussion. While it may technically be legal for the time being to sell a record in one shop with an EULA that says it can't be played on a record player from another, I'm not asking for a legal opinion or even asking any dev to acknowledge anything.

I'm asking a simple question for USERS who either have or have not found that one or more of the libraries can effectively be played without having to switch back and forth between 5 different ecosystems in a single project. That's just a basic workflow necessity at this point. Making drum based music, the ecosystem overload has become unmanageable.

I'm not "making sample libraries in any form, commercial or otherwise..." I'm not "making derivative works..." I own the drums. I'm just trying to trigger them like my friend wiring up his pots and pans with piezos. From a practical standpoint, it's no different than using a homemade drum trigger.

Thank you for pointing out that the EULA situation is bonkers and that a consumer bill of rights is an inevitability in our future. This is not a legal or philosophical question. It's a practical one. Having 5 different drum modules running on every session is killing my system, and it REQUIRES a practical solution.

[Burillo]

BFD packs are XML metadata, so mapping the kits shouldn't be that hard. i think sounds for BFD 2 were uncompressed, while BFD 3 had them compressed. i'm not sure if they're encrypted or not as i never attempted to decode them, but i wouldn't be surprised if the BFD "BFDLAC" format is just FLAC with some additional metadata.

[whyterabbyt]

... You can check the rest of the EULA's for yourself, Im sure. But expect a resounding consensus of 'no, f**k off or get sued' to be contained therein....

A friend of mine builds his own MIDI drum kits for his own amusement. As a practical matter, he needs to use head units which were designed to be used with the kits with which they were sold.

That's nice. But completely irrelevant.

Call him a criminal if you like. I find the notion unworthy of discussion.

Yes, me too, because its a complete red herring.

I'm asking a simple question for USERS who either have or have not found that one or more of the libraries can effectively be played without having to switch back and forth between 5 different ecosystems in a single project.

You got a simple answer.

From a USER. Wooo.

The fact you dont like it is irrelevant.

I'm not "making sample libraries in any form, commercial or otherwise..."

Porting a drum sample library from one software package to another software package is making a sample library. Whether you acknowledge that or not.

I'm not "making derivative works..."

Yes, you would be, actually.

I own the drums.

Irrelevant.

I'm just trying to trigger them like my friend wiring up his pots and pans with piezos.

Yeah, where 'just trying to trigger them' involves creating a derived work from a closed sample format.

From a practical standpoint, it's no different than using a homemade drum trigger.

Yes it is. Very different.

This is not a legal or philosophical question. It's a practical one.

Whether you want to bury your head in the sand or not, I gave you a practical answer. These are generally closed, undocumented, proprietary formats.
The legal stuff was additional to that. You're welcome.

[whyterabbyt]

but i wouldn't be surprised if the BFD "BFDLAC" format is just FLAC with some additional metadata.

I would. You can read Skot McDonald's paper on it if you want.

https://computermusic.org.au/media/2017 ... duced2.pdf

[Burillo]

I own the drums.

Irrelevant.

this is a tricky question actually.

technically, this is not only irrelevant, but also not true owner of a BFD library owns a license to use this library in a particular way, they don't own the library itself. no copyright is granted by purchasing a license for a BFD library.

of course, whether these kinds of restrictions on usage 1) make sense, or 2) are even legally enforceable is a different question (AFAIK clean room reverse engineering for compatibility/interoperability reasons is allowed), but if we take EULA literally, this would be in breach of the EULA and the developer can potentially revoke your license for doing so (again, whether this would be smart and/or good publicity for the developer is a separate question).

it seems to me that the OP is confusing "is" with an "ought" - while i would like to live in a perfect world where this kind of usage wouldn't be in breach of EULA, but we don't live in that world, and it's silly to pretend otherwise. i doubt Angus (or whoever works on BFD now) would be breaking down your door with a SWAT team if you do this on your own, so in practice this restriction won't matter.

that said, Chicken Systems' entire business model is pretty much built around providing tools for this exact use case (converting sample libraries from one format to another), so it's not like there's no precedent for this kind of thing.

[Burillo]

but i wouldn't be surprised if the BFD "BFDLAC" format is just FLAC with some additional metadata.

I would. You can read Skot McDonald's paper on it if you want.

https://computermusic.org.au/media/2017 ... duced2.pdf

oh, cool, didn't know that. thanks!

[MeldaProduction]

Most of these formats are "secret", so it's pretty much impossible to import them. You could hypotetically sample them, I thought about making such feature, but it's hard to say how useful that would be and legally it seems kind of a grey area.

[whyterabbyt]

that said, Chicken Systems' entire business model is pretty much built around providing tools for this exact use case (converting sample libraries from one format to another), so it's not like there's no precedent for this kind of thing.

Well, that's the thing isnt it? Locked, proprietary formats are popular for that kind of content. The way to port non-open-format libraries from one closed format to something else is to reverse engineer the closed format and write a software tool that does the conversion. And post-DMCA that has to be done 'clean room'.

So someone has to undertake that task.

Im assuming the OP isnt capable, because otherwise they'd be doing it instead of expecting a magic bullet. That means the someone isnt them, its some hypothetical third party.
But if the someone is a third party, then it means that they would then also have to get away with it, ie be allowed to provide it to other people.

And whether the OP likes it or not the 'get away with it' is entirely underpinned by all the legal/philosophical stuff.
Which is probably why Chicken Systems don't do certain sample formats.(*)

And ChickenSys certainly dont do all the ones the OP is asking for. Noone does.

(*) and they also dont do the encrypted versions of various formats like Kontakt and UVI, even if they support the unencrypted variant of that format.

[Burillo]

And whether the OP likes it or not the 'get away with it' is entirely underpinned by all the legal/philosophical stuff.

it's also a matter of practicality as well. BFD may well send a cease-and-desist to anyone who sells a commercial tool to e.g. convert between BFD and SD3 formats, but i doubt they would bother if it's a python script on someone's blogspot page, nor if OP simply boasted on KVR that they did this, rather than provide an actual tool to do it.

Which is probably why Chicken Systems don't do certain sample formats.

keyword being "probably", as in, we don't actually know if that's the case it could also be that there are simply too great technical hurdles (encryption, etc.) to overcome for them justify the investment.

And ChickenSys certainly dont do all the ones the OP is asking for. Noone does.

well, no harm in asking, is there?

[Annabanna]

I own the drums.

Irrelevant.

this is a tricky question actually.

technically, this is not only irrelevant, but also not true owner of a BFD library owns a license to use this library in a particular way, they don't own the library itself. no copyright is granted by purchasing a license for a BFD library.

of course, whether these kinds of restrictions on usage 1) make sense, or 2) are even legally enforceable is a different question (AFAIK clean room reverse engineering for compatibility/interoperability reasons is allowed), but if we take EULA literally, this would be in breach of the EULA and the developer can potentially revoke your license for doing so (again, whether this would be smart and/or good publicity for the developer is a separate question).

it seems to me that the OP is confusing "is" with an "ought" - while i would like to live in a perfect world where this kind of usage wouldn't be in breach of EULA, but we don't live in that world, and it's silly to pretend otherwise...

Or perhaps not everyone who sees through a different lens is ignorant.

Perhaps it is silly as a user to concern yourself with whether the EULA states that you pledge your eternal soul in exchange for the privilege of using the thing you've already paid for. Whether or not the dev is under the mistaken impression that they will decide for me how I use the product is right near the bottom of the list of stupid things for me to waste my time worrying about.

Obviously for a developer enabling EULA workarounds is a whole other can of worms. Since I'm clearly not a developer looking to market a product, this is effectively a discussion about TOS toilet paper.

... and it's silly to pretend otherwise.

[Burillo]

Well, I could just as easily say, if you don't like the EULA it comes with, don't use the product - it's not like you're entitled to use it any more than the author of the library is entitled to your money. It's a transaction, to which you agree when you purchase it. Has copyright law lost its mind and went too far? Yes, a long time ago, and way too far, and it seems to be going even more insane as time goes by. But you don't just get to ignore it because you don't like it. If you feel so strongly about it, go to court and make your case for why this developer's EULA is bonkers, or join an activist group and advocate for the law to change.

[Annabanna]

But you don't just get to ignore it because you don't like it....

Incorrect.

I have all sorts of home automation, car modifications, and probably more other examples than I could count of just exactly why it's a waste of time to concern yourself with this nonsense as a user.

[Burillo]

But you don't just get to ignore it because you don't like it....

Incorrect.

I have all sorts of home automation, car modifications, and probably more other examples than I could count of just exactly why it's a waste of time to concern yourself with this nonsense as a user.

...which are an entirely separate category as far as law is concerned. With something like a car, the "first sale doctrine" applies and you own the car, and can do whatever you want with it (not all modifications will pass road safety regulations though). You own the car, and can do with it as you please. With a drum library, don't actually own it. You own a permission to use it, that's as far as it goes. So home modifications etc. are entirely irrelevant

This is similar to how you could, for example, root your phone, but then don't be surprised if some software wouldn't work on a rooted phone - including software you paid for. You own your phone and can install DOS on it if you are determined enough, but you don't own the apps on your phone, and thus aren't entitled to do with them as you please.