(I\'m editing the top of this post to point out that I am no longer on the Giga development team and do not speak for the Tascam folks. Due to my long past history with them, some people may have gotten the wrong idea. Anyway, at this point, I am a full time free lance instrument designer and composer. I\'m no longer privy to any official info any more than the rest of us but I am aware of rumors and other forum threads that have addressed these issues and have been able to decipher potential future Giga features. To be on the safe side, I\'ll keep my theories to myself, lest anyone mistake them for offical word or something. In fact, due to the large number of people I work with and consult and my regular posts on this forum, they are especially carfull to not share too much with me too early. I\'ve also tweaked it for accuracy and better worded some of it)
I’ll address several issues as best I can without giving away any proprietary information I have regarding library products.
There are many things I have been asked (and required by various agreements with library creators) to keep quiet about for the time being but there is much helpful info that I can share here without getting into too much trouble.
I’ll address a few issues.
1. My opinion and ideas on 24 bit.
2. My 2 cents on Copy protection issues
3. Creating instruments while waiting on 24 bit resolution.
4. Anything else I can think of while writing this.
First of all, I think 24 bit resolution in Gigas future is a no brainer. (I would hope so anyway) The current GigaStudio 2.5 can accept 44 or 48 khz 24 bit samples into the editor and then dither them down to 16 bit for playback during the save to disk operation. From that point on, the samples are permanently 16 bit inside the gig file. 3.0 is suppose to allow full 24 bit playback from what I hear.
So that brings up the question of how to produce a library right now while we wait for 3.0 to be released. At first I thought that Articulation (.art) files would solve that problem but they seem to only work on already completed and saved .gig files. They are great for exchanging edits for completed .gig files with each other but I have not managed to have them accurately put together a .gig file after importing the wave folders into a completely new instrument. So, the best solution for now, is the “replace folders” option. As long as you don’t change the names of the wave files that you are working with or the folder names, (16 bit and 24 bit versions) you should be able to build 16 bit versions of your .gig files and save them. When 3.0 comes out, we should be able to simply load the 16 bit .gig file into the editor, use the replace folder command to replace all the folders one at a time with 24 bit versions (with identical folder and wave names) and save the file and have a 24 bit version ready to go. So we can all work on the individual components and even some basic dimension instruments and convert them to 24 bit versions in 3.0 with that “replace folder” command. We can then glue them together in the 3.0 editor for more complex dimensions. Of course we can build complex instruments in 2.5 and break them apart if needed for reassembly in 3.0.using the reduce dimensions command. Hopefully 3.0 will offer a simpler way to reduce dimensions. There are several options to say the least to work on future libraries with the current GigaStudio and then quickly get them ready for 3.0 when it is released without completely redoing the work. Ideally, QL Orchestra will be simple enough to not need all the extra dimensions that 3.0 is reported to possibly have.
What about 24 bit high sample rates and polyphony and cpu usage when using QL Orchestra and other future 24 bit libraries?
24 bit will certainly be noticeably richer when compared with 16 bit versions and the extra pairs of mic options in Nicks library will also be indispensable once we start experiencing their sound.
What I recommend is to simply compose in “low res 16 bit 44k stereo” (who would have thought that would be titled low res) with one of the mic sets. (same polyphony and cpu that we are currently use to) This alone would still require plenty of horsepower and multiple systems to do it all at once in an ideal situation. Then we would pull up performances of the 24 bit instruments (probably one or two at a time) and capture those digitally to a hard disk environment in 24 bit with all 6 QL Orchestra tracks of microphones, perhaps in sections or stems. Then mix that down for your final and the results should be very stunning. If you have budget for a room full of computers, then go live if you can but I think even the Hanz Zimmer style systems will be taxed by these new high res multi track samples. Even in that case, I might still be necessary to capture high res stems separately. I think this library and many of the new ones would even over take Zimmers enormous system at full resolution with the 6 discrete tracks going. Add any layered crescendo expressive samples and that will really eat up the computer so in the end, it will probably require separate passes of capturing 24 bit stems when the composing is done in most cases.
The ever-dreaded Copy Protection
I do not know the technical details of how it will work (or if it is even part of the new spec though these threads make me suspect so) but I do know that it will rest entirely with the library developers whether to use it at all, and how strict and user friendly to make it for the end user. I also have heard of possible dongle systems (third party and usable right now) that could be used that would be my personal preference and could be used with 2.5 as well as 3.0 or any other software sample library format. These dongles can protect up to 150 peices of software (or libraries) with a single dongle.
There is a ton of wisdom on this thread about this issue and much food for thought. Copy protection of some sort for libraries is inevitable but this feedback will help Tascam and Library developers think through issues that may not have been thought of before. I know I learned something new here.
The glut of libraries:
I don’t know what to think about the huge selection of orchestra libraries that are coming out or how to advise. (Currently, I’m partial to Dan Dean and GOS libraries) I mean, even if you have all the libraries on hand, finding a way to organize and use them all is mind boggling to say the least. All I know is that the competition is good for the customers as in most areas of the free market. It keeps the developers on their toes creating better and better products and software. This library stands a very good chance of surviving the fight since it is one of the best-recorded libraries (if not the best), simple to use and completely done in one environment.
When I first heard about it, I thought, “oh great, yet another damn orch library, just what we need, oh well, good for the giga platform anyway”
Now that I know the details, I think it will stand out and survive after all.
Can’t wait to hear it.