Implementing an auto updater/notifier?

[hisefilo]

@d-healey this thread makes me think a Software Center can be done with actual HISE tools. like Arturias Software center or NI app.

Is this possible? What do you think

[d.healey]

@hisefilo I'd recommend doing it as an Electron app. You might be able to do it with HISE but it will be quite limited.

[d.healey]

@hisefilo Now that I've played with the Server API I think it's definitely possible to make a software centre type app.

[hisefilo]

@d-healey yeahhhhh mate!!!!! Will be digging on it soon.

[ustk]

I definitely think it's possible... I'm just afraid that if it's cracked, everything would be available at once

[d.healey]

@ustk Not at all. You never put anything that requires security on the client side, that goes on the server side.

[ustk]

@d-healey me->reassured() :)

[d.healey]

An idea I've been having, which I think we should all discuss, is a download manager for HISE based plugins/expansions. I'm building one for my own plugin, I was originally going to include the functionality inside my plugin but for various reasons I think it would be better as a separate app. I considered building it with Electron, but since HISE has such a sophisticated file api and server api, and also the ability to encrypt/encode/extract/install expansions it makes sense to build it directly in HISE.

Play, Native Access, Spitfire, SINE, Pulse, VSL, I'm sure we could add a few more to the list. And now every single one of us is thinking of creating a new one :D I'm not so sure it's the best thing for users to have to install a separate download manager for every single vendor.

Mine will of course be open source, but it has occurred to me that maybe I could make it suitable for other developers to use too. They would have to be using WooCommerce for their webshop and there would be some other requirements to make everything work nicely. I'll provide a wordpress plugin that has the necessary API endpoints and of course these can be modified as needed for each developer's setup.

The app won't require the user to sign-in, it will be decentralised, each vendor will provide a code when the user buys a product that can be entered into the app and it will get the product from the vendor's server - a bit like Steam keys.

This benefits the user as there is no single point of failure, they won't have their buying habit tracked by a single company, if they move to a different machine they just need to export/import their codes.

It benefits the developer because they don't have to pay a third party to supply a download manager service and the developer is in control of their own products. If the developer wants to watermark their software or incorporate some kind of DRM they are free to do that on the server side and on the installed plugin side, the app itself is agnostic in this regard and merely acts as a channel between the user and the products they've purchased on the developer's server.

I think it would also be good if as well as acting as a download/software manager the app also provides a catalogue of products that the user can click on to visit the vendor's website.

Let me know your thoughts/suggestions.

There is currently no way to get a reference to a generic folder, such as the user's VST2, VST3, AAX, or AU installation locations. I think out of those VST2 is the only one that doesn't have a standard location.

@Christoph-Hart Would it be possible to add location constants for these? Or perhaps have some kind of user customisable location. I appreciate that we don't want to give access to the entire file system but letting the user pick a location seems mostly harmless.

[Dan Korneff]

@d-healey Sounds cool. I'm looking at designing one for my needs with Electron as we speak, but keeping things within the HISE ecosystem are very attractive to me.

[Christoph Hart]

Hmm not so sure about this. Of course the idea of everyone in this forum having their own installer that they just took from a template and slapped their logo on it sounds like a nightmare for the end user, but on the other hand I can imagine that there will be a lot of overhead trying to design a open source solution that works with multiple servers.

What are the downsides of including it in the plugin + having a manual option for people who dislike the plugin download path? The authorization + installation to the expansion folder is being done by the plugin but the user can choose whether he wants to download the samples automatically or if he wants to get a list of static download links to the .hr1 files?

[d.healey]

@Christoph-Hart said in Implementing an auto updater/notifier?:

What are the downsides of including it in the plugin

In a single plugin the downsides are minimal. However let's imagine 10 developers each release 10 plugins and one user buys all one hundred (don't laugh it could happen :p ). Now the user has to log in to 100 different plugins (and perhaps get them past their firewall). Each time they open their DAW template every instance is going to call up to a server to check for updates or do some DRM thing.

Each developer will come up with their own, slightly different, implementation of the downloader/installer. When a user disconnects from the internet all the plugins will react in a different way, some will be poorly implemented and popup with errors, others will crash the DAW.

Each of those 100 plugins will also need a separate installer, each one has to be built, codesigned, notarized, and maintained.

And the thing that got me considering this in the first place... a plugin should just do it's job, it shouldn't be a download manager or product catalogue.

My idea separates the download/installation process, reduces maintenance for developers and simplifies the install process for the user.

The main difficulty, as you pointed out, is making the system work with different server configurations. So we'd need to agree a standard, which is better than us all having a different standard. The system I proposed is fairly narrow in terms of what server configurations it will talk with, but there's no reason we couldn't expand it in the future.

[orange]

@d-healey I think one single "Downloader / Installer / License Manager" idea is very good and effective.

I've been using many many plugins of other companies. But I think Plugin Alliance Installation Manager is one of the best approaches. There is no need to discover America again. It has below features and it would be awesome if Hise made implementation has these features too:

• Directly downloads the plugins as zip files and extracts to the selected plugin locations. (No plugin installers requred anymore if you store the plugins as zip files on your server)

• So with this method, user can select the plugin formats that who needs. Well, no unnecessary server traffics anymore.

• Suitable for all kind of licenses such as: Single Products, Bundles, Subscriptions.

• It can activate or deactivate plugins/bundles/subscriptions individually. For example you have an All in One subscription package but at the same time a full perpetual license of a single plugin. So you decide to activate perpetual plugin license in Machine A. Or subscription licenses in Machine B....etc

• It has meta data fields that shows image and information about the single products / bundles.

• If a new plugin released, this software grabs the plugin and adds to the list automatically, which is an awesome feature also!

[d.healey]

That looks cool. Having unzipping has been suggested before by someone, I think in this context it could be very useful. It would even allow the download manager to handle non-HISE instruments, such as Kontakt patches or SFZ files - of course this would need to be implemented in HISE too and I think Christoph has enough work for now :)

[ustk]

zip management is already implemented in JUCE so wrapping an API shouldn't be too hard, well, however it is for me…

[d.healey]

@ustk said in Implementing an auto updater/notifier?:

zip management is already implemented in JUCE so wrapping an API shouldn't be too hard, well, however it is for me…

Well we can add that as a future upgrade :)

[d.healey]

This is kind of what I had in mind:

[d.healey]

I think I just realized a huge flaw in my idea. Expansions are encrypted with a unique key which is also used to decrypt and install them. Even if we could set the key via scripting I can't think of a way to transmit it from the server to the client securely... Might have to go with a per vendor solution after all and find other ways to mitigate the downsides

[orange]

@d-healey One template software. Per vendor can adjust and use it acording to their needs. I think there is no need to unify brands under one.

[d.healey]

@orange This is the current situation and the thing I wanted to avoid.

[d.healey]

Here's a possible solution, the download manager only does download managing and placing files in appropriate folders. Each plugin that uses expansions can check on startup a specific location for any newly added expansions and extract/install them.

This removes the need to transmit encryption keys and also means I could build the app with electron instead of HISE.