Although it feels like a nifty trick, putting the background rack into a song, I think I’m going to keep mine well and truly hidden in the “background”. It’s nice to have all my rig-wide setup in there, hidden so I can forget about it, and not be tempted to drive it in any song-specific way. I’m just wondering if there could be undesirable side effects if for example modify it by song states etc.
Understood - interesting idea!
But what I’m after would be to have the Background Rack audio and midi ports accessible in my songs. This would allow me to
- Put all my master processing (master compression, volume, EQ) into my Background Rack (with multiple input ports) and route all my songs to these ports to be processed before output to physical output ports.
- Create a MIDI pre-processing chain for my various master keyboards in the master rack (different velocity curves), merging them into one global rack output (instead of MainKeyboard). Would be a really cool way to customize the response of different hardware keyboards and still feed them to my songs in parallel, so that I can freely choose to play either my little 49 keys production board on my desk or my 88 keys stage masterkeyboard next to it and still have a similar feel.
- create a standard microphone processing chain (compressor, EQ) in the global rack that I can then feed into my songs for further individual processing.
For this, I would need to be able to select the global rack stereo inputs as routing targets in songs, as well as select global rack MIDI outputs as routing source. As I’ve learned from @FantomXR, I can use loopback ports to fiddle my way around this, but TBH, it looks a bit complicated and difficult to understand when looking at my songs, so having Background Rack ports directly available in songs would be preferable to this convoluted work-around.
@brad: how about it?
Cheers,
Torsten
1 Like
@Torsten’s suggestion would be really cool. I think many of us have a standard rack we put at the end of our songs as a general output processing rack (levels, compression, EQ etc). Being able to set this up as standard and hide it away in the background would be nice, to reduce song clutter.
Similarly, being able to pre-process incoming audio and MIDI before reaching the song would be really handy. And it would be great to use background rack states to choose different incoming hardware configurations (big keyboard rig vs pub rig, gigs where you have extra mic or guitar inputs etc) while keeping the inputs at the song level abstracted.
But I wonder if it would be better to have new racks for these - dedicated input and output background racks, which have constrained ports (input rack would see all the environment input ports, but only have configurable rack audio/MIDI outs, and the output rack would have configurable audio/MIDI inputs but environment output ports). Then maintain the existing background rack as it is, for backwards compatibility, and as a place for general background processing that doesn’t fall into the pre or post processing categories.
Neil
2 Likes
This is totally possible. I used the backgroundrack for exactly this cases on my last gig. In my BR I’ve inserted all audio in- and outputs as racks. So this allows me very quick routing options f.e. if you send the click to various destinations. No problem with that.
But you are right: You have to name the ports so that you don’t get lost!
I will try this. Thx
Tyger, Steve Steele shared a video on YouTube shown below that, although about Digital Performer, Vienna Pro and Kontakt, shows some Kontakt optimizations that, if I remember the video correctly, could vastly improve your load times. It is an awesome trick that only loads the actual samples for the notes you really use, as I recall. (I don’t have time to watch the video again right now, but I’m pretty sure it was Kontakt he optimized here…) From his description of the video, it seems I remember correctly:
I show you five ways to optimize Kontakt 5 in a large film scoring type template to take up less of a memory footprint, use less CPU threads and how to save the optimize version in your template.
Intros video I cover:
- Kontakt’s Multiprocessor Support (CPU core count).
- Kontakt’s Database and how to manage it.
- How Kontakt’s uses DFD and how to set it for your system.
- Kontakt’s CPU Profiling Mode
- How to correctly Purge Kontakt.
Perhaps this will be helpful to you and others loading large sample instruments.
3 Likes
Hi @Torsten
This seems like a perfectly reasonable to me, but…
Just to be clear this wouldn’t give functional difference over adding the background rack to the song right? It’s simply a shortcut in that the rack’s audio and MIDI ports would be available in the song without having to reference the background rack.
Or, are you asking for something else?
Nope, that’s exactly what I am asking. The difference being that this helps clean up my songs and have clearer separation between global and song-specific processing
Also, if I referenced the background rack in my songs as a linked rack, wouldn’t the bindings I have defined in my background rack be instantiated twice - and midi commands be triggered twice? I have a number of bindings for ‘next state’, ‘next song’ etc in my background rack - I’d be afraid they get triggered twice when inserting the background rack into my songs - need to test this…
Cheers,
Torsten
Hi @Torsten
The rack will only be instantiated once - the in-song reference is just an extra activation reference on the same instance so the bindings won’t be invoked twice.
Brad
OK, that helps!
Still, the advantage of not linking to the global rack FILE in my songs would be the ability to have completely different global racks for my studio machine and my live setup (since the path for the global rack is managed in Cantabile’s settings and not within the songs). My songs would reference the global rack, and I could customize global racks to my different hardware configs, with customized MIDI velocity / aftertouch curves for each of my boards, with mappings to convert various sliders / buttons to perform standardized tasks, etc.
So, if there isn’t some arcane reason why the global rack ports couldn’t be available for my songs, it would really open up some nice customizing options for my various setups - without resorting to the convoluted method of creating “dummy” ports for loopback.
Cheers,
Torsten
1 Like
I’m experiencing the exact same problem. It will take almost 5 minutes to load a song using Kontakt 5.1
When it comes to loading samples in Kontakt or a ROMpler like Keyscape at the end of the day nothing is going to improve performance like a SSD. When I got one it was life changing. Set list loads went from almost 10 minutes to about 50 seconds. I preload everything and all my changes live are instantaneous.
1 Like
Hi, a SSD for the kantaktlib is an absolute “must-have”. The problem I had disappeared and I din’t know why. Kontakt loads in Cantabile as fast as in Forte. Two days ago, suddenly the problem with loading time returned.
By chance I found out, that it was depending on an Windows update, that was not yet installed. After installing all updates, everything works fine again. (4 to 6 GB of data approx 5 sec.)
1 Like
Gah! Gotta love Windows. Glad that got sorted.
Although you got this resolved, Kontakt’s slow loading times are fairly infamous. Here’s some similar discussions that might help:
https://www.native-instruments.com/forum/threads/kontakt-5-5-absurdly-slow-sample-loading.263053/
1 Like
I have found that a patch re-save usually get rid of that initial lag before Kontakt starts loading samples, where it’s apparently just trying to find them in the first place. Not a batch re-save like they talk about in the articles (that scares me) but a simple patch re-save, not even re-saving the samples.
1 Like
Batch resave does, indeed, speed up loading in situations where the samples have separated themselves from their program, requiring Kontakt to search - but, once a project is saved and recalled, in any DAW for that matter, the pathway should have been saved anyway. In a nutshell, a new project could take longer to locate samples, but an existing one which has already found the samples should already be as optimal as possible, YMMV.
1 Like