I\'ve been using GOS for a while, and love it. I also really appreciate the updates and great support.
But I notice it being fairly latent in its timing/response. I realize there is a natural lag in the attack for the strings\' sound to develop, but it seems that it lags just a little bit too much. All other Giga samples on my system, even GOS Pizzes, seem reasonably tight, timing-wise. I offset the GOS parts in my sequencer and its fine, but perhaps you have further suggestions, insight etc.
I recently replied to a similar question in private email. Here’s a modified version of my answer:
Brass, woodwinds, and (especially) percussion have very fast initial waveform rise times. Generally less than 30ms. Strings are different (with the exception of percussive sounds, like Pizz). Waveform rise times vary greatly with bow stroke type. Some short bows can be quite fast but long bows generally have natural rise times between 300 and 750ms. All instruments contain information in the initial attack that is crucial to their identity. With strings, a developer must make a decision: trim the sound of the initial bow stroke of the long bows while adding an artificial, but fast, envelope to achieve responsiveness or keep the natural sound of the initial bow stroke and live with the more sluggish response. Responsiveness versus realism. We came down on the side of realism. From a developer’s standpoint, you can’t give people both options on the GigaStudio platform without incurring an impractical penalty in library size – at least not until GigaStudio allows larger attack buffering values than it does at present (maximum is only about 45ms). Interestingly, certain other platforms, like Kontakt, can do both without a penalty.
For most people this is not a big problem when playing the parts into a sequencer because the user tends to compensate for the slower bow strokes while playing and listening to the other parts. On the other hand, the slower rise times become very noticeable when used with notation programs or with “piano roll” entry of data. In these cases the data is generally entered in quantized form so all samples for a given beat or subdivision are being triggered at approximately the same time (within the splay of the serial MIDI data stream but without compensation for the inherent characteristics of the various attack speeds). Timing compensation must then be used. The ease of compensation depends upon your software. Sequencers like Logic allow you to offset an entire track without destructively affecting the actual MIDI data in the track. This takes just a couple of seconds to get the job done. Other programs may require additional work. As always, the most natural results for timing will be achieved by actually playing the parts in, one by one, with expression.
In the full version of GOS there are some options that can improve responsiveness in the long bows. Use of the LEG instruments in conjunction with MaestroTools gives the ability to have extremely responsive long bow attacks whenever the sustain pedal is depressed. This is achieved with “masking” samples. The downside is the great polyphony demands of these instruments. Non-LEG instruments use GPC-1 (cc#16) to control attack envelope speed. Lower values have faster response times. This is also true of GOS Lite long bow instruments. Finally, it is certainly possible to do custom editing of the .gig files in the GigaStudio Instrument Editor to speed up the attack times if you are willing to take that route. Depending upon your preferences it could be as simple as setting all GigaStudio default controller attack envelopes to very small values or as involved as actually editing the attacks of each of the samples in an audio editor. By removing a portion of the attack of the sample itself and applying a short attack envelope in GigaStudio you could improve responsiveness – but always at the expense of realism. The more you remove, the more you lose.
P.S. to Steve: Feel free to post on this forum - it\'s for users as well as developers. Often though, specific questions are better addressed to us directly, rather than posting. You\'ll usually get a faster answer too.
I would be interested to hear more about this as well. For a while I thought this forum was for sound developers only, so I was meek to correspond here. Now I assume it\'s a place for general discussion on a particular developer\'s product, in this case GOS. I still wonder if this form is intended to be open to users.
But I\'ll tell you my experience. Playing with attack control (cc 16) can get a certain amount of variation in attacks. Most of my composition is very \'pop\' oriented, so I tend to want more immediate response from my sustained string patches. Because of this I set all my GOS strings to a default of 15 ticks/120 ticks/beat at the track level. Then, when I come to a section that uses short bows, I (usually) select the particular notes and slide them back by 10 ticks (actual amount varies with situation).
I have always rationalized that string libraries have to capture notes naturally, and that real string players actually anticipate notes and begin a bowing some few milliseconds prior to the arrival of the precise beat, in order that they are \'on\' when it comes. I mean, versus an instrument like an organ where the delay between thought, action, and sound is much shorter.
Since the majority of my passages are sustained notes, I see them as the lion\'s share of my notation and that\'s why I advance the entire track... so the notes will appear on the sequencing grid, for the most part, lined up nicely. Usually in short/quick sections there are so many notes that there\'s not much benefit in being snapped to the grid, i.e. you\'ll probably have to actually look at the note\'s properties to be certain of its start time.
I think people that normally enter music by playing at the keys have less concerns, as they are imparting the \'feel\' in \'run-time\' if you will. I almost always (except for fundamental melodies) write in a piano roll view.
Hey Ted - in Cake there is a place to set Time offset on the track (there is also Velocity and Key, mebbe some others). This value is in ticks, so it will have a varying effect based on the ticks/beat setting of your project. In any case, this will offset the timing of your entire track. For instance, I set mine to -15 for GOS in 120 ticks/beat projects. Now, when a note is supposed to sound, for instance, on the first beat of a measure, Cake will actually send the note on command 15 ticks earlier than other not-offset events. You can play with the amount of offset until you get the \'feel\' you want.
The only problem you will have is if you use that same track to also play some short bows or other fast attack sounds. In this case, I select these notes individually and \'slide\' (see Slide in help)them \'back\' the other way (this is actually adding back some positive offset to compensate for the negative track-level offset I already imposed). I guess I am reiterating what I wrote above.
Hope this helps in addition to what others might add.
I am still using Cakewalk, not Logic. Do you have some idea what I can do in Cakewalk?
Do I understand the technique you suggest, that two following notes overlap, before the first sound quits, the next begins?