Propellerhead Forum

Propellerhead Forum (https://www.propellerheads.se/forum/index.php)
-   Feature Suggestion Forum (https://www.propellerheads.se/forum/forumdisplay.php?f=7)
-   -   Automated and incremental updates, please! (https://www.propellerheads.se/forum/showthread.php?t=165772)

buddard 2012-08-17 14:59

Automated and incremental updates, please!
 
I don't understand why it's necessary to download 1.12 GB for a minor update? Using incremental patches instead would save huge amounts of bandwidth I think.

Also, the procedure to manually move around the factory sound banks in order to prevent them from being deleted is ridiculous.

Reason is a modern and user-friendly application in all other respects, is it really that hard to implement a one-click updater? It could even be done from within Reason itself. "A new version (6.5.1) is available. Do you want to upgrade now? [Remind me later]/[Update]/[What has changed?]"

Pretty please with sugar on top?

(End of rant)

baresark 2012-08-17 15:48

agree 100%

VillaNDubstep 2012-08-17 17:57

This deserves a +1
Just waiting for someone now to come along and give a page of info as to why this wouldn't be possible lol

joeyluck 2012-08-17 18:43

It may not be recommended, but I've never had an issue just copying over the Reason Application itself (and not copying over anything else).

SteveDiverse 2012-08-17 19:52

Quote:

Originally Posted by VillaNDubstep (Post 1118000)
Just waiting for someone now to come along and give a page of info as to why this wouldn't be possible lol

I could do that :) however, it should be possible, but...

Releasing a full application instead of 'patches' results in a more cohesive, stable system with efficient performance.

To effectively be able to do incremental releases, you have to break the application into lots of little pieces. The incremental release is then accomplished by releasing only the pieces that change.

The breaking up of the application into smaller pieces, however, generally results in slower performance, and instability. (Ironically, thus requiring more frequent updates)

It would be very nice if you could put the soundbanks anywhere, and specifically not in the reason folder, and have reason point to them, so you don't have to touch them to do an update

-OR- have the installer install around them or move them out and back for you.

buddard 2012-08-20 14:20

Steve, I'm sorry but I don't buy your explanation.

Using patch files (look up the programs "diff" and "patch", they've been used for almost 30 years), the props could use the exact same file structure that they have today.

What you do is that you create a patch file (using "diff" or similar utility) containing just the differences between the old and new versions of the changed files and package it with the installer, resulting in a considerably smaller file to download. The installer will automatically bring the existing files up to date using the patch. So there's at least no technical reason to replace entire files that I'm aware of. (Unless the files in question are encrypted, but I doubt that this is the case.)

tomduff 2012-08-20 15:50

Quote:

Originally Posted by SteveDiverse (Post 1118105)
Releasing a full application instead of 'patches' results in a more cohesive, stable system with efficient performance.

To effectively be able to do incremental releases, you have to break the application into lots of little pieces. The incremental release is then accomplished by releasing only the pieces that change.

The breaking up of the application into smaller pieces, however, generally results in slower performance, and instability.

There is no reason why the above would be the case.

Quote:

Originally Posted by buddard (Post 1119449)
Using patch files (look up the programs "diff" and "patch", they've been used for almost 30 years), the props could use the exact same file structure that they have today.

Diff has been commonly used for 30 years (or more), but applies to plain text, not binaries.


I won't disagree that the Reason update process certainly leaves room for improvement though.

buddard 2012-08-20 16:22

tomduff, while the original "diff" and "patch" programs may have been text-only, the principle has certainly been applied to binary files since. You may perhaps remember a little game called "Doom" in the early 90's? That's right, the game was updated by applying patches...

A more recent example is git (a version control system). In order to conserve space, it only stores the differences between every version of each file. While this is how most version control systems work, the difference with git is that it doesn't distinguish between text files and binary files.

To get back to the use of this technique in updating software, there seem to be a number of products on the market that manages the creation of automatic patches, I found several in 5 seconds by just googling "how to create incremental installation".

My point is that this should be an almost trivial problem to solve for a programmer with reasonable skills, and the props are certainly not lacking in that department. The amount of time (multiplied with the number of users) and bandwidth saved alone should be able to cover any additional licensing and/or development costs involved in making this happen...

So more than anything I'm just surprised that we still have to download a 1+ GB file to get a few bug fixes...

tomduff 2012-08-20 18:12

Git supports binary diffs by the use of conversion algorithms that allow some binaries to be turned into plain text (i.e extraction of the test from a word doc) or comparable information (i.e. the properties of a JPEG) for comparison purposes. A diff between 2 raw binaries is nearly always meaningless (unless you really are interested in the difference between the sequence of 1s & 0s) and this is why it won't let you do other source control activities like merge on binary files.

The actual differences (deltas) in git are not between the files, they are between snapshots. I.e. even adding a new file to an existing repository can create a delta since it is between the previous state of the entire repository and the new one - assuming the size of the delta is smaller than the new file (and some other rules around delta depth)

I am not disagreeing that patches could be created though - as binary deltas can obviously be determined.

rogerlevy 2012-08-20 18:24

I think the main reason this would not work out for users is that there would be too many opportunities for errors to happen in the update process.

Also, I don't share your opinion about micro updates. I really, really do not like my software changing on me every single freaking day. Google is a big culprit of not heeding the saying "if it ain't broke, don't fix it." Seems like sometimes they move shit around just to look busy.


All times are GMT +2. The time now is 08:29.