Propellerhead Software

Go Back   Propellerhead Forum > Feature Suggestion Forum

 
 
Thread Tools Display Modes
  #1  
Old 2012-08-17, 14:59
buddard buddard is offline
 
Join Date: May 2009
Posts: 96
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)
  #2  
Old 2012-08-17, 15:48
baresark baresark is offline
 
Join Date: Dec 2010
Posts: 30
agree 100%
  #3  
Old 2012-08-17, 17:57
VillaNDubstep's Avatar
VillaNDubstep VillaNDubstep is offline
 
Join Date: Jan 2012
Posts: 2,023
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
  #4  
Old 2012-08-17, 18:43
joeyluck's Avatar
joeyluck joeyluck is offline
 
Join Date: Mar 2011
Posts: 3,771
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).
  #5  
Old 2012-08-17, 19:52
SteveDiverse's Avatar
SteveDiverse SteveDiverse is offline
 
Join Date: Nov 2003
Posts: 3,778
Quote:
Originally Posted by VillaNDubstep View Post
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.
__________________

HP Pavillion DV7T-3300 Laptop | i7 Q720 @ 1.6 GHz | 4GB RAM | Win7 Pro 64-bit
m-audio Axiom Pro 61 keyboard controller || iPad2 | RetouchControl DUO | TouchOSC | LoopBe30 MIDI
m-audio Mobile Pre USB (original) audio interface | ASIO4ALL || RØDE NT-3 mic
Reason 7.1.1 || Pulsar | Saturation Knob | Rough Rider | TSAR-1 | Uhbik-A | Re-Tron | Polar | Echobode | Uhbik Q | Uhbik F | Morfin XF | Uhbik S | Uhbik D | Uhbik G | CV Suite Line Processor | wbl5515 | Uhbik P | RE-2A | Radical Piano | Audiomatic | Synchronous
  #6  
Old 2012-08-20, 14:20
buddard buddard is offline
 
Join Date: May 2009
Posts: 96
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.)
  #7  
Old 2012-08-20, 15:50
tomduff tomduff is offline
 
Join Date: Jun 2012
Posts: 71
Quote:
Originally Posted by SteveDiverse View Post
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 View Post
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.
  #8  
Old 2012-08-20, 16:22
buddard buddard is offline
 
Join Date: May 2009
Posts: 96
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...
  #9  
Old 2012-08-20, 18:12
tomduff tomduff is offline
 
Join Date: Jun 2012
Posts: 71
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.
  #10  
Old 2012-08-20, 18:24
rogerlevy rogerlevy is offline
 
Join Date: Nov 2010
Posts: 1,933
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.
 

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



All times are GMT +2. The time now is 14:44.