I want to pre-process a guitar sound before sending it to an audio path in the Background Rack. Since guitar effects vary from song to song, I don’t want to put every possible effect in a chain, but rather to create an ‘internal’ input port. For each song that uses the guitar input, I can either create a direct rout to the internal input, or send things through effects processing first. Kind of like this –
INPUT A (from USB audio) ------> {effects chain} ------> BGND RACK INPUT
Right now, I’m doing that by creating an unassigned Input port with loopback –
I know this is an older post, but a couple thoughts…
-IIRC its not recommended to process audio thru the BG rack due to increased latency. Brad has posted this in the past. Sorry I don’t recall which but you can search for it.
-Like most here I use a linked EFX rack with numerous plugins, I think mine has about 10. Suspend those not used in a Song State, save it as a rack state or the Song State with appropriate state behavior set. Suspended plugins use miniscule CPU. Even using all 10 is still small CPU if you use CPU efficient EFX.
I learned this from Corky and Dave Dore years ago. Just my .02
Tom
@twaw Thanks for the pointer. I’ve been using the BR for processing Leslie sim audio for almost 18 months now, and if there is extra latency by doing it that way, it can’t be very much. (FWIW, Cantabile reports that my audio setup has 3ms audio latency.) I certainly don’t see/feel I difference between organ played on my Nord Stage sent to the BR, and organ generated inside Cantabile by Waterfall B3 or Blue3. Maybe @brad has improved the situation in recent versions?
It makes logical sense for me to place the Leslie inside BR because I use organ in 90-95% of my songs, and I have a binding that changes the song every time I change a program on the Nord: this would cause a brief pause in the audio each time a new song loads.
There is no change to the fundamental logic: piping audio through the loopback port incurs one additional audio buffer of latency. This is due to the fundamental architecture of loopback ports: their input is created by the current processing cycle; once the current processing cycle is completed, its output is transferred to the physical output ports as well as to the loopback ports.
That means that if your output latency is 3 ms, you’ll have another 3 ms added for all audio you process through the loopback ports. 6 ms isn’t horrible latency, so you’ll hardly hear it (2 meters of distance to the speaker instead of one), but with larger buffer sizes, this will possibly be felt.
When you process an external device like a Nord Stage through the background rack, you’ll have (simplified) three buffers of latency: first, the input buffer, then the current audio cycle (where you just pass it through to the background rack), then a third for processing the background rack and sending to output. With your low buffer size, this will be 9 ms, still not painful…
Some of us have been in discussions with @brad on a possible separation of the background rack into an “input rack” that allows to feed audio and MIDI from physical inputs via some plugins directly into the current processing cycle for the loaded song, and an “output rack” that allows the current song to send audio directly to that rack for output processing - all this within the current audio cycle. This would help us provide some standardized pre-processing before signals hit the current rack, plus some overall post-processing, without incurring any latency penalty.
Not sure where this sits with @brad’s current development priorities - maybe an update?
@Torsten Thank you for the explanation. So, if I understand it correctly, running my Stage into a Leslie sim running in the Background Rack results in 3 audio cycles latency – 9ms in my case – while running the same Leslie sim in a song would have 2 cycles latency (1 to bring the audio in, another 1 to send the processed audio out). That’s not all that different in the end.
Interesting about that possible update you described …
Currently I’m struck trying to get this engine rework complete. Been a bit distracted by some personal stuff, but it’s also a complex set of changes so it’s taking some time (too much time).
That said, this rework should provide a good framework for adding separate global input/output racks and I’ve been keeping it in mind during the rework.