nesthaa.blogg.se - Cpu overload with pianoteq 5

Do you have other instances of PianoTeq in other songs/racks? Perhaps this is an issue with PianoTeq when multiple instances are loaded (even if only one is currently activated).Early 2014 MacBook Air i7, 1.7GHZ base (turbo boost to 3.3 GHZ) with 8GB RAM, 512 SSD, Sample Rate 48k, 128 Samples (2.7ms)Įarly 2015 MacBook Pro i5, 2.7 GHZ base (turbo boost to 3.3GHZ) with 8GB RAM, 128 SSD, Sample Rate 48k, 128 Samples (2.7ms) I know PianoTeq has a CPU Overload Protection option - perhaps try turning that off?Īlso, I’d try turning off either PianoTeq’s multi-core rendering or Cantabile’s multi-core support, they might be fighting against each other.įinally, it’s interesting that this only happens when pre-loaded set list is enabled. That would seem very odd to me and I can’t think of a reasonable explanation off hand, but to eliminate this as a possibility - does this only happen with PianoTeq or does it happen with other plugins too? My next suspicion would be something about the plugin is not rendering notes as quickly as possible. Scrolling through both log files all events are averaging about 3-10 milliseconds between Cantabile receiving the event and it getting passed to the plugin.Īll that’s to say, as best I can tell Cantabile’s audio/MIDI processing pipeline is working as expected. This is all as expected when using a 10 millisecond audio cycle. Line 3: the event hits the pianoteq plugin 5 milliseconds later (see column 2)

Line 2: it was immediately injected into Cantabile’s audio engine

Line 1: Cantabile first received the MIDI event at time 56084

The numbers are thread id and logging level - ignore these for this.

The second column (eg: 103) is the elapsed time since the previous line (ie: column 1 current line minus column 1 from the previous line).

The first column (56084) is the absolute time in milliseconds since Cantabile started.

Also note that because of the logging the times logged will actually be a little slower than when logging is disabled - ie: the logging will be making this worse than normal, but it still all looks OK to me. Firstly, you’re running and audio cycle of 512 samples at 48Khz - so each audio cycle is about 10milliseconds. I’ve looked at the logs and the timings between the two look almost identical.