Challenges: Musical
My iLok has become faulty, therefore I currently do not have access to all my EastWest libraries. I limited myself to Kontakt based libraries I own. Furthermore, I tried to use non-ensemble instruments, so I refrained from using Albion sounds (in the end I used 3 tracks: for high- and low- strings, and low- brass).

With non-ensemble section sounds, each instrument's part need to be thought out. It will also tend to sound more separate than a naturally recorded ensemble. With writing separate parts comes the temptation to write each part with slightly different variations and embellishments instead of just doubling the main motifs. I hope I have achieved this,to a certain extent.

Challenges: Techincal
Beginning with my previous piece, I have started to use a single instance of Kontakt with multiple MIDI channels driving different patches in it. With this latest piece, I decided to go a step further: to try and use a single instance of reverb that all my instruments can aux-send to.

My previous workflow was to just use each Kontakt instrument's reverb from the patch's interface, even if they were all of the same type. This results in resource redundancy. So I figured out how to aux-send the signal from each instrument to a stereo aux-out from Kontakt. Each instrument would be totally dry (no reverb), and has a different level of send to the aux bus. I then routed Kontakt's aux out and assigned it to one of FL Studio's mixer strips, and applied FL Studio's reverb plug-in. I must say the reverb's performance is quite decent.

With this signal flow set up, I positioned each instrument section to its own space in the audio field, with a balance of wet (reverb) and dry to emulate distance from the listener. Now that it's finished and done, I find that the piece is still too wet on the whole.

The second technical hurdle I had to overcome was note-stealing and glitching in my playback (and final rendering). There is something not working right with my laptop set-up. I keep encountering glitches/crackling and note-stealing. As the piece got longer and the parts increase in number, I started to encounter glitches and note-stealing behaviour from my DAW.

When I finally finished the piece, I could not get a single part that was not glitching and having its notes cut short before the intended durations were through. This was made even more apparent due to the slow tempo of the piece, where notes need to sound for longer lengths of time.

Therefore I started to troubleshoot by looking in several places. This was my investigative steps in chronological order:

1) I started to change the audio buffer for the sound driver I was using. Tweaking this resulted in different parts glitching and crackling at different places. I could not find a value that allows the piece to play perfectly.

2) Alvin suggested that Kontakt may be streaming sample data off the hard disk in real-time. If the hard-disk could not keep up, then it would result in glitches and note-stealing. There was a DFD toggle in Kontakt (very likely to stand for 'direct from disk'). This toggle allows users to turn it on and off for instruments developed for Kontakt version 2 and below, to force them to stream from disk. Trying that did not give me improved results. Still, I appreciate Alvin's help, and his resourcefulness!

3) This leaves me with the only course of action: to bounce out each instrument in its own audio file, then re-assemble them in a separate multi-track session in FL Studio. So I tried to solo only the channel I wanted to render, and to my horror it was still unable to solve the problem! Note-stealing was still happening, even on single tracks where the patch was mainly playing single notes at any one time. Using this approach however, I managed to reduce a lot of crackling and glitching caused by audio-buffer under-runs, since I could now adjust a suitable buffer size for every patch that gets solo-ed and separately rendered.

4) Next, I looked into the feature in Kontakt that allowed me to purge and reload samples from each or all of the instruments in the single instance of the VST client. I unloaded all samples, then solo-ed the target patch that I needed to bounce out, then reload all samples only for that instrument. This way, the RAM would only be used by the single patch. It still did not work.

5) I tried to switch between FL Studio's foreground / background rendering. I did not really know the difference, so I checked out the documentation. It just says "background rendering allows you to use other applications while the rendering is taking place". Pretty informative, that. I was really hoping to get a more techincal description of what's happening, but I was to be disappointed.

6) I remember that Sonar has a feature that allows the user to set a track to 'archive' state. That is to say that in the 'archive' state, the track's properties would not be expected to change, and even if the user tries to change it, the change would not be real-time. In other words the system would be able to free-up more resources for other functions that Sonar needs to take care of.

Then I remembered the "zip" function in the main channels view. It collapses the channels. I was hopeful that it would perform a similar function, where it would really ignore all the midi events happening in those tracks, and I am unlikely to unmute or change their properties during playback. It did not help. On reading the documentation, the zip feature is only cosmetic in function.

7) This next step I did was 2 steps in one. I had 14 tracks (and 14 unique instruments) in my piece. I decided to try and have 14 different FL Studio project files (.flp), each one for each track I would render out. In each of these files I would delete all channels and keep only that channel I was going to render out. Also in the Kontakt instance of that file, I would delete off all the other patches from the stack of patches inside Kontakt. This would leave only a single channel with midi notes, velocity, expression events (if any). It would also have a single instance of Kontakt with just one instrument existing inside.

Thankfully, this works most of the time. For those that did not work on the first try, I re-purged the samples, then reloaded the samples on that single remaining instrument in my scene. I tried doing just 1 of these 2 steps, and it still produced note-stealing in many tracks, so in the end I just decided always to delete all unneeded tracks in FL Studio, and all unneeded patches in Kontakt.

The conclusion I can draw from here, is that somehow the presence of other tracks, either in FL Studio's tracks or in Kontakt itself, would somehow always be processed during playback, and thus taking up resource, and thus causing note stealing. This occurs even though those unwanted tracks are muted. I have many tracks with CC data (either cc1 mod wheel, cc11 expression, or both).

I can only speculate that when all these elements are present, it would somehow drain enough system resources to cause note-stealing behaviour in the playback. When I took them away, leaving only 1 track in FL Studio, and a single instrument in Kontakt, it produced satisfactory results most of the time.

This is a very time consuming way to work. For every track I bounced, I failed many times. For each time I render, I have to listen through 2 minutes (thats the length of my piece) to make sure there are no glitches or stolen notes in the track. I spent many many hours before coming to the workaround I now have. Even so, it is not an elegant nor very practical workaround with projects of longer duration.