What format do you use to distribute plugins+samples?
-
@gorangrooves -- and having an authorisation system that understands both single purchases and bundles....
-
@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 :)
-
@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.
-
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.
-
@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.
-
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.
-
@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.
-
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.
-
@gorangrooves said in What format do you use to distribute plugins+samples?:
I strongly believe that the best user experience is to have a single installer that installs the plugin and all of the samples,
Can't be notarized if it's more than 50GB though.
-
@d-healey said in What format do you use to distribute plugins+samples?:
Can't be notarized if it's more than 50GB though.
50GB? You have a single library that large?
-
Not yet, but I'm working on it :) There are many libraries from the "big" developers in excess of 50GB (Hans Zimmer strings, for example, is 250GB!).
-
@gorangrooves said in What format do you use to distribute plugins+samples?:
I strongly believe that the best user experience is to have a single installer that installs the plugin and all of the samples
But the user has to download everything for a simple update?
-
@gorangrooves said in What format do you use to distribute plugins+samples?:
After all, the HLAC format is only temporary. The plugin needs to extract it into the raw wav files before they are used.
Nope, you're confusing HR1 with HLAC. HR1 is a wrapped FLAC chunk and HLAC is the actual codec that HISE supports natively. There are many advantages of using HLAC over raw wave files, faster loading times, less memory usage & disk space.
-
@Christoph-Hart I guess I am :)
@ustk said in What format do you use to distribute plugins+samples?:
strongly believe that the best user experience is to have a single installer that installs the plugin and all of the samplesBut the user has to download everything for a simple update?
No, they don't if you provide an update as a separate installer only for the plugin. I am having a special WP plugin developed for me that will allow organizing of download files for WooCommerce into folders and subfolders. So, end-user will see one download button for their purchased product, but when they click on it, they get a pop up, so they can pick their OS platform and whether they want full installer or just the update. Such a plugin does not currently exist publicly, so as soon as the final bugs are ironed out, I will make it publicly available for free.
Interested?
-
@gorangrooves that's what I thought, but does it mean new user will see full installer with old version as long as the updated plugin installer?
The WP plugin you mentioned seems a good idea, although I am not working on a sample based instrument yet, but it'll come… -
@ustk The idea is to always have an up-to-date full installer (including the samples) for users installing the product for the first time and just a plugin installer for users updating from the previous version.
The WP plugin I am developing will enable you to specify what is what, without creating mess and clutter. It even has support for icons for each file and folder.
Here is a preview.
-
@gorangrooves That makes sense...
Your plugin looks very promising :) -
@gorangrooves - this seems to cover two scenarios..
- All new install
- plugin update
but misses the third:
- samples only update..
-
@gorangrooves said in What format do you use to distribute plugins+samples?:
@ustk The idea is to always have an up-to-date full installer (including the samples) for users installing the product for the first time and just a plugin installer for users updating from the previous version.
The WP plugin I am developing will enable you to specify what is what, without creating mess and clutter. It even has support for icons for each file and folder.
Here is a preview.
Looks very useful. Is this compatible with woocommerce?
-
@Lindon The picture is only for a visual reference. In the actual plugin, you can set any number of folders and files and set their individual icons. So, you can customize to whatever best suits your needs and current situation.
@orange Yes. This is only compatible with WooCommerce :) It integrates with their native download system and expands on it. If you disable the plugin, it just goes back to the native display, which is an individual product instance for each downloadable file (messy).