It is a little surprising to me the number of libraries out there that are tons of disc that actually have half the data on them. For example, what good does it do you to buy a 15 disc library if some of the discs have 200-400 megs on them and data that is redundant and could have been put on the same disc instead of splitting them onto two or more discs just to rename a program?
It just seems to me that as a developer that consumers would want the most for what they are paying for. I think people deserve more. Is it really worth all the marketing hype to say you have a 35 disc library if it could have been produced on 8 disc\'s. The consumer deserves better programming and better editing (no dead air on the ends!!)
To all developers.....this is real simple...if the shoe doesn\'t fit then don\'t sweat what I just said!
First of all there are several 10+ disc libraries...secondly, like I said in my last sentence. If the shoe fits then it does...if it doesn\'t it doesn\'t. Please don\'t assume that I am speaking of anyone of anything in particular. I made it real clear I wasn\'t pointing anyone out.
Fully agree. And as a comsumer who just dished out $^2 on a studio upgrade recently, over 2/3\'s the patches on the disks I received are unusable in terms of mockups etc. Why? Becuase most of the patches are articulation duplications. For simple example, why do I need patches that are DV, Pizz, NV/Pizz Modw when the latter will cover the first two former? Layering unisons? Nope...doubles the instrumentation so it sounds like 2x\'s the number of player on a note - you have - e.g. 12 violins now sound like 24 with 12 plaing arco and 12 playing pizz
Anyway, it continues to into other areas as well such as vel and keysw variants and samples I will never have a need for.
Just give me a decent library that doesnt hog memory IMHO
It must be a slow news day in Gigaland. It probably costs me more to store that extra CD or three than it would to burn it. I myself prefer that many smaple developers seem to think that organization is more important that skimping on a few CDs. So this is what we\'re reduced to bitching about sample developers shipping a couple extra CDs, like the extra buck or two would make a difference in the price of GOS.
<BLOCKQUOTE><font size=\"1\" face=\"Verdana, Arial\">quote:</font><HR>Originally posted by pantonality: It must be a slow news day in Gigaland. It probably costs me more to store that extra CD or three than it would to burn it. I myself prefer that many smaple developers seem to think that organization is more important that skimping on a few CDs. So this is what we\'re reduced to bitching about sample developers shipping a couple extra CDs, like the extra buck or two would make a difference in the price of GOS.
Time to step back and look at the bigger picture.
I think your missing the point. For example, LOP is four discs. Each disc has on average 698 megs on it. If were to have spread that out accross 8 discs instead of 4 my cost for production would have gone from roughly $3500 to $7000. Now if I have to pay $7000 rather than $3500 guess who the difference in price gets passed too?
PS...let me say again since there are a lot of \"sue happy\" people out there. I haven\'t mentioned anyone or any library.
[This message has been edited by donnie (edited 04-06-2002).]
In regard to your comment about the costs being passed onto the consumer:
At least in the case of GOS I don\'t at all think this is this issue. The proof of this is in all the free updates: several discs have been issued for free to users since its initial release. It\'s all about choices and flexibility.
I don\'t think for one minute that GOS is \"expensive\" because of the number of discs it\'s released on.
But your overall comment reminds me of a gripe I had when I was purchasing Roland series libraries. Orchestral Family discs were fully loaded, but many other discs were only 200 megs and you didn\'t know it until you bought it.
Fair practice would be to indicate how many gigs/megs a libary contains, based on ACTUAL data not number of discs. In fact it would be nice to see this as standard on every library to help indicate what you are getting.