What format do you use to distribute plugins+samples?

gorangrooves

I am curious as to what approaches people here use to provide plugins along with the sample libraries to customers.

Do you provide a single installer with the samples included, thus making one large file, or do you split them into separate downloads (a smaller one for the plugin and a large one for the samples)?

I guess that for a user, a single installer would be easiest since everything is in one place. But, since Apple requires you to upload your end product to their server for notarization, that will mean uploading some very large files.

What approach have you taken?

Dan Korneff

I have my sample library as a separate zip file here.

gorangrooves

@dustbro So, users download 2 files and manually extract the samples to whatever location they want?

d.healey

I provide installers as individual downloads (one per operating system) and the samples as .hr archives (as exported from HISE). The archives are split into 1GB so the number of archives depends on the number/size of the samples in the library. Sofia Woodwinds for example has about 10 parts to download.

Lindon

@d-healey said in What format do you use to distribute plugins+samples?:

I provide installers as individual downloads (one per operating system) and the samples as .hr archives (as exported from HISE). The archives are split into 1GB so the number of archives depends on the number/size of the samples in the library. Sofia Woodwinds for example has about 10 parts to download.

Yep after a lot of trial and error (mostly from the poor people using MacOS) Dave's approach above has shown to be the best, with some conditions:

zip your Mac Installer ON THE MAC
zip your Windows installer ON YOUR WINDOWS MACHINE

the second of these may not be required but better safe than sorry - essentially the Mac turns out to be rubbish(very very picky) at unzipping anything

Dan Korneff

@gorangrooves said in What format do you use to distribute plugins+samples?:

@dustbro So, users download 2 files and manually extract the samples to whatever location they want?

Exactly.

d.healey

@Lindon I don't bother zipping the installers:

gorangrooves

I've been thinking a lot about what the best practice would be for delivering purchased plugins to customers. While I have experience in selling digital products for over 5 years using WooCommerce, the nature of plugins brings additional challenges to keep things as clean, tidy, and straightforward as possible.

The objective is to deliver the best possible user experience, from purchase, through download, to installation and use.

Here are things to consider, each presenting their own challenge.

Customers should perform as few actions as possible.
They should not have to read manuals or watch complicated videos to know what and how to install.
Any confusion as to what is required to be downloaded needs to be eliminated.
Each plugin product consists of at least 2 elements: the actual plugin and the sample library
Each plugin needs to be provided for a variety of platforms (Win, Mac, Linux) and a variety of formats (VST, VST3, AU, AAX)
Plugins need to be connected to their respective samples.
Serial number(s) need to be entered to unlock the plugins
Product bundles!

I imagine the ideal scenario as follows:

You select a product in the store and complete the purchase as quickly and as seamlessly as possible, without unnecessary things to fill out. You are taken to the downloads section of your automatically-created account, where you have access to all of your downloads now and in the future. Your products are displayed in a clean, uncluttered way and it is easy to pick and download what you need. Serial numbers are also provided for each product. Each product or a product bundle has a single file to download. Upon download, you click on your file and start the installer. The installer guides you through the whole process and there are no manual actions needed to be performed at the end. The installer installs the plugin formats of your choice, in the directories you specify and installs the sample library in the directory of your choice. The installer creates the text file needed to tell the plugin where the samples are located and places it in the plugin directory.
When you start your DAW and load the plugin, you are asked to enter your serial number, which you copy+paste. The plugin is unlocked and you can start playing right away. No need to locate samples again and reload your plugin.

An identical scenario should happen when you purchase a bundle with multiple products. The only difference is that you will be using a bundle serial number, so you only need to enter it once in a single plugin. All other plugins will be automatically unlocked.

So, in order to make this happen, each plugin should have a single installer for each platform, which includes both the multiple plugin formats (VST/AU...) and the sample library. If you plan on delivering to 3 platforms, then 3 files will need to be added to your product listing. That means that in the DOWNLOADS section of user account, by default they will see 3 downloads for each product (Win, Mac, Linux). That can easily get out of hand, as 3 products will produce 9 visible instances, which will look like 9 products, creating unwanted confusion. A custom solution is needed to present only a single download button per product, which when pressed opens up a drop-down or pop-up to select your OS, which then downloads the relevant file.

This dropdown/ popup system becomes even more critical if later you update your plugin and in addition to the full installer, you want to provide just the plugins installers for existing customers to use to update. Then, instead of 3 files per product, you will have 6 files per product!

Product bundles: while WooCommerce supports bundling existing products as a single combo product, that would present a terrible UX. Instead, such bundles should be created as new products, containing all plugins and all samples into single installers.

By having only a single file that needs to be downloaded and run in order to install a fully functional plugin, we avoid possible confusion scenarios where users download only the plugin, but not the samples (or vice versa). The more confusion we can eliminate, the better the initial impression will be, the higher the satisfaction and the less time we need wasting on support, explaining the same things over and over.

So, the two main challenges remaining is programming installers to place sample location links and customizing WooCommerce to organize multiple downloadable files.

Lindon

@gorangrooves -- and having an authorisation system that understands both single purchases and bundles....

gorangrooves

@Lindon said in What format do you use to distribute plugins+samples?:

@gorangrooves -- and having an authorisation system that understands both single purchases and bundles....

I have implemented the bundle authorization to the "simple copy protection done right". Works like a charm :)

andioak

@Lindon said in What format do you use to distribute plugins+samples?:

zip your Mac Installer ON THE MAC

zip your Windows installer ON YOUR WINDOWS MACHINE

the second of these may not be required but better safe than sorry - essentially the Mac turns out to be rubbish(very very picky) at unzipping anything

Indeed even a simple thing like a zip-file can turn to dust between systems. But on macOS we have keka, a free and open source file-compressor, that also has 7-zip and compression grade 1-9, that also works for zip-files (and also splits files and combines during compresion/unpacking). I have tested 7-Zip for windows and one of the libraries seem to outperform the others in size of .wav files or alike. The lzma, which was around 20% smaller size for the same setting and unpacked fine on my macbook (osx 10.10).

Keka on mac has an option called "Exclude Mac Resource Forks", that removes the .DS_store and other junk in hidden conditions. The stuff no end-user should ever see.

Cool thing too, I checked with keka on their forum and they are fine with all developers and companies just including the app itself on their .dmg files. So no sending your users to other places to find that tool that unpacks your files. Cause let´s see a person with little computer skills try to unpack a 10-piece .zip or .7z file series. Hahaha. Yeaahh.. aaaahhhmm... SUPPORT!

A light user manual for installing/unpacking in a pdf and you can save a huge chunk of data delivery. If you have costs for a cdn.

d.healey

@andioak

on macOS we have keka, a free and open source

It's not. https://github.com/aonez/Keka#so-where-is-the-source-code

I suspect it actually violates the GNU GPL since it includes libraries that are licensed under the GNU GPL (not LGPL) but maybe they are not linked in the binary or something.

Cause let´s see a person with little computer skills try to unpack a 10-piece .zip

If you use the built in hr compression for your samples then HISE will unpack them during the first run. A better option (which I'm looking foward to using) is to have the plugin download and install the samples directly.

andioak

@d-healey said in What format do you use to distribute plugins+samples?:

I suspect it actually violates the GNU GPL since it includes libraries that are licensed under the GNU GPL (not LGPL) but maybe they are not linked in the binary or something.

Aaaaah licenses. Don´t ya just love them! :/ Proper sticks in the wheel.

The hr compression seems like a good option. But can one just deliver with that as an archive/zip option and still use .wav or .aif in the end folder? Or is that a part of the HLAC format? Anyway, a self-unpacking zip:ish archive for cross-platform is a thing out of a wonderful dream. Its not like there aren´t a lot of stachexchange questions about it.

d.healey

@andioak

But can one just deliver with that as an archive/zip option and still use .wav or .aif in the end folder? Or is that a part of the HLAC format?

You could deliver a zip contains the HLAC samples (don't use raw audio as it uses more disk space for no gain and HISE sample maps seems to get confused by it). But an hr archive is the same as a zip, just specialised for HISE and the extraction tool is already built into your plugin.

andioak

@d-healey said in What format do you use to distribute plugins+samples?:

You could deliver a zip contains the HLAC samples (don't use raw audio as it uses more disk space for no gain and HISE sample maps seems to get confused by it).

I got an instrument that is already in use and uses .wav, I am just adding another way to play it. So multi-format is the way I am going to deliver it, which makes .wav the only option (or .aiff / pcm), for me. After all, delivering an instrument that is around 5GB plus on top of another format a user may already be using in mixes is a waste of hdd space, and web traffic / online storage for me. But for a new un-released instrument, it´s the best option.

If there is an issue with sample-maps and the raw audio files the only option is to solve that issue instead, cause that really makes me worried. (if that´s a bug, I sincerely hope it´s high on the list)

But an hr archive is the same as a zip, just specialised for HISE and the extraction tool is already built into your plugin.

Excellent. I will have to tinker a bit with that. If it can deliver raw audio files.

gorangrooves

I have not had any issues with sample maps confusing any wav files. After all, the HLAC format is only temporary. The plugin needs to extract it into the raw wav files before they are used.

I strongly believe that the best user experience is to have a single installer that installs the plugin and all of the samples, hooks them up to the plugin, and has everything ready to go by the time user launches the plugin for the first time. That's the route I will be taking for sure. If you leave a possibility that a user can overlook installing something (like additional samples install), you will likely have additional support requests to deal with.