What a year 2011 has been for those of us who use technology as a significant part of our musical life! The parade of great new string libraries continued and is still apparently continuing. A partial role call includes: EastWest Hollywood Strings; Los Angeles Scoring Strings 2.0, which is a major upgrade; Kirk Hunter’s Concert Strings II with TVEC 3 programming; Cinematic Strings, which has a major upgrade due soon; Miroslav Vitous new String Ensembles, Composer’s Dream; 8DIO Adagio Violins. And of course, there are still all the fine libraries that raised the bar some time ago from VSL and Sonic Implants, among others. It really has reached the point where in my humble opinion if you cannot produce some pretty great sounding sampled strings in your composition with these libraries, whichever ones you prefer, you simply lack the know how.
But 2011 was particularly notable for a bunch of new brass libraries: EastWest Hollywood Brass; Cinesamples’ Cinebrass and Cinebrass Pro; Kirk Hunter’s Concert Brass II; VSL’s Dimension Brass; and once again, some older favorites like Project Sam’s Orchestral Brass and other VSL and Sonic Implants classics.
Then there are the previously released combo libraries from Project Sam, Symphobia 1 & 2, that were joined by their Orchestral Essentials and Spitfire’s Albion, among others.
2012 promises to bring us wonderful new woodwind, choral, piano, guitar, drums and percussion libraries to add to the embarrassment of riches.
So how do we sort through all these choices and what are our criteria for evaluation? If we wish to avoid being disappointed, what should we expect from developers and what do they have a right to expect from their users?
I will give you my take on this and will welcome hearing yours, dear readers :) (Note: I am employed part time by EastWest as their Online Coordinator.)
How do we choose?
1.Demos provided by the developer: The problem is that some of the guys who do these are so skilled at maximizing the good traits of a library and minimizing the not so good that they make every library they demo sound great. Developers are often asked to provide quick “naked” demos but this is problematic because when they do so, frequently then people in forums jump all over the library for their perceptions of where the library lets down, so it is sometimes a no-win situation for them.
2.Try-Sound: Useful, but limited selection.
3.Out of the box user walkthroughs and demos: Helpful but potentially misleading when the user is not equally skilled with all of them or consciously or unconsciously favors one over another.
4.Peer recommendations: Helpful, but so, very subjective. Even among composers I greatly respect, there is such a diversity of opinions on any given library as to be more confusing than enlightening for the potential buyer.
5.Going to a friend’s studio and trying a library for several hours: This is IMHO the best way, but still if it is a deep library, only partially an answer.
The bottom line is that like most things in life, there are no guarantees. You do your due diligence, pay your money, and take your chances.
How should we approach beginning to use the library?
1.Read the manual and/or watch the videos. Some people hate this, but in the long run it saves you more time than it costs you.
2.Start to write with them as you normally do. Don’t play “gotcha” by trying to find out everything the library does NOT do well. You will find those things out in the normal course of your writing and it is entirely possible that therefore things that are a problem for some users will virtually never be a problem for you.
3.When you find something that is not working well for you that you do a lot, find out if it is indeed the way the library is designed, or if it is a bug or a system specific issue.
4.When all else fails, choose another library that does that particular thing better in your estimation, or write something else.
Those of us with a lot of experience writing for live players learned to do #4 a long time ago. As a musical director/arranger I soon realized that for example, I could write quite high notes for trumpet players here in L.A. that they would handle with no problem but that when I was in Omaha, the players there, although good musicians, simply were likely to crack playing them for a sustained period of time. So I wrote to the players. It is in my opinion also the smart way to deal with sample libraries and virtual instruments. None of them are going to do absolutely everything to your satisfaction, so you need to write in a way that maximizes their strengths and minimizes their weaknesses. After all, you are likely not a perfect composer, right?
Also, we need to understand what the library is intended to do best. The name is frequently a clue :) EW’s Hollywood series is designed with a film score aesthetic in the Hollywood tradition while VSL has traditionally tried for a European symphonic orchestral sound. Neither is particularly geared to non-symphonic style work, although on any given piece you may feel that they work well for you. Fable Sounds’ Broadway Big Band is obviously geared towards pop, R & B, and jazz. The same is true of Chris Hein Horns or Sample Modeling’s highly regarded instruments. So they are more likely not to work for you in a symphonic simulation context, although again, maybe they will in some pieces.
What do developers owe us?
1.The product should do and behave as they say it does. When it doesn’t and they are made aware of it, they should try to replicate the issue. If they determine it is in fact a bug and not a system specific issue, they should rectify it in a reasonable amount of time.
2.If it IS a system specific issue, they should try to help the user sort it out, to a reasonable degree. That said, the inter-relationship of competing sample engines with so many hosts and OS choices makes this not feasible many times so we, the users, must learn to troubleshoot somewhat scientifically.
3.Backward and forward compatibility, once again, to a reasonable degree. Nothing is future proof and all things we buy may have a shelf life.
4.Reasonable attempts to engage us in discussions about what we would like to see in future updates, UI design, etc. because it is just good business and something they owe themselves as well as us.
What do we owe developers?
Some people say nothing because “the customer is always right.” I do not accept that. We are first and foremost human beings and we owe developers what we owe all people until they give us a reason not to.
1.Respect: It is a difficult job. Everyone wants great products at a bargain price and the marketplace is highly competitive and somewhat cutthroat. Few get rich providing us these tools and those that do mostly work ridiculously long hours at it.
2.Presumption of good intentions: Nearly all developers want you to love their products and are not looking to cheat anyone. If they wanted to cheat people, they would work on Wall Street :)
3.An understanding of what the library was designed to do and not designed to do and some practice learning how to use it as it was intended, not necessarily the way we want it to work.
4.Realistic expectations: Hence the tile of this column. As good as libraries are now and as they continue to evolve, you still cannot expect that they will give you everything masterful players with great instruments, creativity and total understanding of the instruments being recorded by a great engineer in a great studio can give you. It is not possible and I for one am glad.
Most disappointment springs from unrealistic expectations and the sample library/virtual instrument world is no exception to that.
I wish you all a happy and healthy 2012 and rewarding composing with all our wonderful tools.