Performance considerations

[Pacocreative]

Hey, I explored a bunch of configurations sensing the ground for my performance setups.
Usually these are mixes of 1-4 modular loopers, 1-4 Granulars, 1 granulaterre, and not much of effects on top, and one looped macro at 50ms.
This sits on Acousmonium with 4 speakers, and a trajectory plugin running on top.

But not all of them run at once. A typical setup would be:
4 Loopers + Granulaterre
2 Loopers, Granulaterre, 2 Granulars
2 Loopers, 4 Granulars

I’m currently running it on a beefy iMac (Late2017, 4-core i7, 4.2Ghz, 64GB RAM).
Idle CPU load is about 10-15%, peaks at 30-35% when I add some stuff.

In theory it seems fine, however I noticed quite a lot of choking and instability.
Could you suggest which of the plugins are most computationally demanding and what are the guidelines to achieve stable, reliable performance?

When is the performance getting the most hit specifically?
1/ When a channel or insert is allocated (project config)
2/ When a plugin is activated? (Say looper inserted into an insert)
3/ When the plugin starts processing (being in use)?

Thanks,

[Pacocreative]

I arrived at really lots of clicking and dropoffs in audio performance, which was generally making it unusable for performance.
So I started a thorough investigation, and here are my findings.
TLDR – not your fault. It’s a particular configuration that made it misbehave.

The symptoms:
– CPU load is NOT exceeding 25-30% (or 20% in LL)
– Noticeably laggy UI
– severe amount of clicking heard in audio outputs
– clicking on speed change in loopers
– clicking while scrubbing through the loopers in freeze mode
– clicking while manipulating MIDI-mapped parameters, which were not even supposed to affect the sound

For example:
– the audio source is a modular looper
– I’m using external controller to manipulate aux sends on other channels
– while I move my knob, the audio degrades

I tested:
– Acousmonium vs stereo
– Various I/O configs
– Using the same interface for In and Out
– Using different interfaces for In and Out
– Using and not using Software Routing (Rogue Amoeba Loopback 2)
– High-priority mode for LL

My go-to configuration was:
LL in high-priority mode ⇀ Loopback 2 ⇀ Main output + monitoring output on two different devices

Apparently, the only configuration producing heavy issues is:
LL in high-priority mode + Loopback as output for software routing

What seems safe is:
LL (no priority) ⇀ Loopback
LL (priority) ⇀ various hardware outputs

Hope this is helpful to anybody falling into the same issues.

Still interested in Phillipe’s / Chris’ recommendations on how to prevent dropoffs in general and assure stage-performance reliability.
I’m still hearing occasional clicks.

[Philippe]

Hi,
There is a ratio between being more in realtime and having better performances.
When I use Logelloop for precise Live Looping and when it needs to be very realtime, I set :

I/O vector size to 256 or less.
Internal precessing to “Very fast” or “Very very fast”

And I don’t use the CPU-hungry modules.

But when I use Logelloop in a more sound design way (Granulars, Granulaterre, many Looper in Time Stretch or ETS, pitches). I set it for performances :

I/O vectore size to 512 or more (depending on my sound card).
Internal precessing to “Fast” or “Economy”

Also, it is very important to set the modules to Off when you don’t use them.

Does this change something in your situation ?

Also, remember that your computer and your processor need to be fast if you want to make many sound design at the same time.
Philippe

[Pacocreative]

Thanks Philippe,

It seems that 128/Very fast works quite fine.
Upon further testing, I’m seeing that using LL with Loopback 2 generally makes LL choke, even not in priority mode, so I’ll avoid that.

[Author]

Posts