Tom Hopkins
04-08-2002, 02:55 PM
There has been a recent thread (“What are you really paying for?”) that addressed the amount of data contained on each CD within a given library. Even though Donnie\'s original post did not name GOS, the library has been mentioned often enough in this thread that I thought I should clear up any possible misunderstandings. I wouldn\'t want anyone to draw the specious conclusion that the discs in the library are only half-full and could have been packed into 8 discs instead of 16. This is decidedly not the case for GOS.
First of all, I should mention something about maximum disc size: During the development phase we found that several of our beta testers had problems reading discs that pushed the approx. 700 meg limit of CDs. This was apparently a problem that occurred most frequently with older CD-ROM drives. We certainly didn\'t want to deal with this same problem in general sales, so we experimented and found that the problems seemed to go away if we kept the total data on each CD to below 650 megs. From that point on we tried to stay comfortably below this limit.
An important consideration was clear organization of files by string section. We didn\'t want to mix files from different sections and lose clarity of organization in the process. We certainly didn’t want to mix files for the sole reason of filling each disc to its maximum capacity. Even so, in the library as released, the average size of discs 1 through 14 is 537 megs. That leaves disc 15, with the final Basses files, as the last primary library disc (227 megs). What about disc 16? Well, it was originally intended as a bonus \"incentive\" disc to be sent to users after they returned their registration. It contained the combination Full Strings Lite file plus an odds-and-ends file of the players tuning up. The full size of the library comes to about 8 gigs, exclusive of the latest updates.
Which brings us to another point relating to the amount of data in the library: The updates. The library has already increased in size compared to its initial offering and the next update adds over 800 megs of new material (not to mention new programming features) to the already large library. Best of all, this update material comes free-of charge to registered owners of the library. That 800 megs (yes, split between two less-than-full discs) is, by itself, as large as some libraries offered for sale.
In the final analysis, CDs are just a way of delivering the sample data to the customer. We also presently offer the data on 2 DVDs and fully expect DVDs to become the medium-of-choice in the future. The organizational considerations (with CDs) largely disappear with DVDs. With new DVD standards on the horizon we fully expect to eventually deliver all library data on a single DVD. We certainly don’t anticipate it becoming a deterrent to sales just because the entire library is contained on one disc. The important number is the total amount of data, not the method of delivery (actually, even more important is the quality of the data, but that’s not the subject here).
Another issue was brought up in this thread: Redundancy. In GOS there is very little sample redundancy . The closest thing to programming redundancy is the existence of both regular and \"warm\" versions of the same instruments. This was made necessary because the filters used in GS are not totally transparent at their neutral settings – we wanted to give people who wished to use external EQ an unfiltered choice - hence, separate instruments. \"Choice\": That\'s the key word here. There are a lot of instruments in GOS. Some may seem, at first glance, similar to one another, but each has a different purpose in application, sound, polyphony demands, or RAM usage. We took the approach that supplying as many choices as possible would serve the greatest number of users - users with vastly different equipment and applications. Any specific user can then choose the subset of instruments required for his/her needs. Many of the choices were derived from the beta testers\' “wish list” and the suggestions of members of this forum. If we had chosen to do \"minimalist\" programming, some users needs would have been left unaddressed. One approach is inclusive, the other is exclusive. The main drawback of being inclusive is: The user must take the time to become familiar with the library in order to make intelligent choices. And it\'s about to get even more involved: The new update adds over 200 new choices - but they\'re really good choices! Most of the feedback we\'ve received to date from users has been enthusiastically in favor of including as many options as possible, but opinions will vary (just look at this forum!).
A tip for those who can\'t take the time to examine all available instruments in the library: Once you find an instrument that suits your needs in one string section, you will generally be able to use its counterpart in the other sections. Compile these into a GS performance and save it as a basic template. Build templates for commonly required applications. From then on you will have your minimalist setup (plus the advantage of all of those other choices waiting in the wings for special situations).
One last point: having lots of instruments within a .gig file has nothing to do with \"sample bloat.\" A .gig file that contains 100 nested instruments will not take up significantly more space on your hard drive than a .gig file that contains only 1 instrument (the main difference is a small amount of additional programming overhead). That\'s because all nested instruments draw upon the same sample pool within the .gig file. Fortunately, when you load any single instrument from the .gig file\'s instrument list GS will only load the required samples for that instrument, minimizing RAM demands. I think this fulfills my essay requirement for the week.
Tom
[This message has been edited by Tom Hopkins (edited 04-08-2002).]
First of all, I should mention something about maximum disc size: During the development phase we found that several of our beta testers had problems reading discs that pushed the approx. 700 meg limit of CDs. This was apparently a problem that occurred most frequently with older CD-ROM drives. We certainly didn\'t want to deal with this same problem in general sales, so we experimented and found that the problems seemed to go away if we kept the total data on each CD to below 650 megs. From that point on we tried to stay comfortably below this limit.
An important consideration was clear organization of files by string section. We didn\'t want to mix files from different sections and lose clarity of organization in the process. We certainly didn’t want to mix files for the sole reason of filling each disc to its maximum capacity. Even so, in the library as released, the average size of discs 1 through 14 is 537 megs. That leaves disc 15, with the final Basses files, as the last primary library disc (227 megs). What about disc 16? Well, it was originally intended as a bonus \"incentive\" disc to be sent to users after they returned their registration. It contained the combination Full Strings Lite file plus an odds-and-ends file of the players tuning up. The full size of the library comes to about 8 gigs, exclusive of the latest updates.
Which brings us to another point relating to the amount of data in the library: The updates. The library has already increased in size compared to its initial offering and the next update adds over 800 megs of new material (not to mention new programming features) to the already large library. Best of all, this update material comes free-of charge to registered owners of the library. That 800 megs (yes, split between two less-than-full discs) is, by itself, as large as some libraries offered for sale.
In the final analysis, CDs are just a way of delivering the sample data to the customer. We also presently offer the data on 2 DVDs and fully expect DVDs to become the medium-of-choice in the future. The organizational considerations (with CDs) largely disappear with DVDs. With new DVD standards on the horizon we fully expect to eventually deliver all library data on a single DVD. We certainly don’t anticipate it becoming a deterrent to sales just because the entire library is contained on one disc. The important number is the total amount of data, not the method of delivery (actually, even more important is the quality of the data, but that’s not the subject here).
Another issue was brought up in this thread: Redundancy. In GOS there is very little sample redundancy . The closest thing to programming redundancy is the existence of both regular and \"warm\" versions of the same instruments. This was made necessary because the filters used in GS are not totally transparent at their neutral settings – we wanted to give people who wished to use external EQ an unfiltered choice - hence, separate instruments. \"Choice\": That\'s the key word here. There are a lot of instruments in GOS. Some may seem, at first glance, similar to one another, but each has a different purpose in application, sound, polyphony demands, or RAM usage. We took the approach that supplying as many choices as possible would serve the greatest number of users - users with vastly different equipment and applications. Any specific user can then choose the subset of instruments required for his/her needs. Many of the choices were derived from the beta testers\' “wish list” and the suggestions of members of this forum. If we had chosen to do \"minimalist\" programming, some users needs would have been left unaddressed. One approach is inclusive, the other is exclusive. The main drawback of being inclusive is: The user must take the time to become familiar with the library in order to make intelligent choices. And it\'s about to get even more involved: The new update adds over 200 new choices - but they\'re really good choices! Most of the feedback we\'ve received to date from users has been enthusiastically in favor of including as many options as possible, but opinions will vary (just look at this forum!).
A tip for those who can\'t take the time to examine all available instruments in the library: Once you find an instrument that suits your needs in one string section, you will generally be able to use its counterpart in the other sections. Compile these into a GS performance and save it as a basic template. Build templates for commonly required applications. From then on you will have your minimalist setup (plus the advantage of all of those other choices waiting in the wings for special situations).
One last point: having lots of instruments within a .gig file has nothing to do with \"sample bloat.\" A .gig file that contains 100 nested instruments will not take up significantly more space on your hard drive than a .gig file that contains only 1 instrument (the main difference is a small amount of additional programming overhead). That\'s because all nested instruments draw upon the same sample pool within the .gig file. Fortunately, when you load any single instrument from the .gig file\'s instrument list GS will only load the required samples for that instrument, minimizing RAM demands. I think this fulfills my essay requirement for the week.
Tom
[This message has been edited by Tom Hopkins (edited 04-08-2002).]