hyperscientist's Recent Posts
Topic explains it all. This is top of the line MacBook Pro 13" 2015 and I play on Seaboard RISE 25, all my software is up to date, there's no expensive background processes, no CPU expensive software running in parallel (I even tried to close everything besides Bitwig to find the issue), charger is connected, battery charged and there's so many artefacts with most of patches that it's just unbearable.
Setting buffer to 1024 samples seem to help, but I start to notice the lag way too much - I can't express myself like this.
Is this kind of performance expected? Do I need a monster computer to run Kaivo?
I only run demo so far, but I wish I could pull the trigger and buy it as it's so good. Currently I'm not sure because of these issues.
That is unfortunate news. It is really sad when a flexible and simple architecture turns out to have just this one major flaw and it forces a rewrite into something less ideal.
Also, did you try Kaivo? It is worse and I wonder wether it's just because of higher complexity of the algorithms (when comparing to Aalto).
That is incredible dedication, thank you so much randy!
Hey, I tried latest versions, so Aalto 1.8.1 (AU.64) demo and Kaivo 1.3.1 (AU.64) licensed.
Aalto works very good! At 44.1khz I can run it at 128 samples buffer with almost no pops. They only happen rarely, so it's possible that it could maybe be an issue with more instruments and fx plugins running at the same time…
And Kaivo is also much better. I get similarly good performance to Aalto at 44.1 khz and 512 samples. Most patches can then be played smoothly and with no pops. Of course I would much prefer to work on smaller sample rates.
The sure thing to trigger terrible pops is to play some note and switch to another app, so that Live is in the background and then for example scroll around. So, to give a concrete example I cmd+tab to chrome browser to write this message and I get short burst of pops in this same time, then I can type the message no problems but when I try to scroll the forum site I get MASSIVE pops.
It must by macOS doing some crazy rendering optimizations. I know that on iOS it used to be that while a user was scrolling the website then that website JavaScript code and all CSS animations would literarily freeze - this way a perfectly smooth scroll could be achieved. Maybe something similar is happening here. The only question is - why doesn't it affect other heavy plugins the same way it affects Kaivo (and Aalto to some degree too).
Model Name: MacBook Pro
Model Identifier: MacBookPro12,1
Processor Name: Intel Core i7
Processor Speed: 3,1 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 4 MB
Memory: 16 GB
Boot ROM Version: MBP121.0167.B18
SMC Version (system): 2.28f7
Intel Iris Graphics 6100:
Chipset Model: Intel Iris Graphics 6100
Type: GPU
Bus: Built-In
VRAM (Dynamic, Max): 1536 MB
I was really looking forward for Macbook Pro performance fixes - not sure if they got into, but in any case: it's still completely unplayable which makes me incredibly sad as I basically thought it's an early christmas present! :(
Basically something is still definitely VERY wrong with the code (and I say it with all due respect!).
I'm on early 2015 retina Macbook Pro with i7 3.1GHz and 16GB RAM running most up to date OS and Ableton Live (all stable releases). There are no CPU spikes only because CPU is constantly loaded to the max. Live's CPU Load Meter shows 60+/-20% all the time while macos activity monitor shows that Live is constantly above 90%, but very often above 100%.
My setup has no problems running any other plugins, not even things like Equator, not even with ridiculously long fx chains all of which I can easily run at 128 samples.
And all that without me playing anything. Just blank project with one midi track to which Kaivo 1.3.0b4 loaded and "box of chimes" patch is selected. When I start playing notes it goes worse.
The CPU load is so high that even the demo noise crackles badly! It's terrible really. Sounds like crickets almost :)
When I record the audio and render it into aiff file then the audio in a file is clear. So it's just current CPU load that mangles the sound (I assume). It's unfortunate really because the only way to show what happens is to use microphone and the only one at my disposal is the my mac's built in one.
Take a look at this file. First you see the clear sound. What I did is I recorder kaivo track on a midi track, then exported it. The second part is recorder from the microphone - that's a midi-kaivo track playing live. Yes, it's THAT bad at 128 samples. It is a bit better at higher settings, but it's meaningless, because it is still too bad to play at any setting that would give reasonable latency. It's noticeable better if I close Kaivo plugin window but only slightly.
https://www.dropbox.com/s/garqti9gelt73in/boxofchimesb4.aif?dl=0
One last thing: every other plugin I own, including u-he ACE, ROLI Equator, Pianoteq, TAL emulations of Juno60 and 101 and it all works flawlessly with buffer of the size of 128, possibly even less (I didn't investigate in details, so maybe for extreme cases it wouldn't be good, but in general it works great!). Also, Aalto doesn't work very well either, so some code must be shared between these two that causes this (at least part of it).
thetechnobear is definitely onto something! I connected my computer to an external display 1920x1200 over HDMI cable and then closed the lid to turn of built-in screen and it helped profoundly. Glitches almost stopped for 8-voices setup with or without plugin window open. I can still hear a crackle now and then, but that maybe happens every 10 seconds or so. I pushed my luck a bit and tried 128 samples, but it's still unplayable.
Ok, so here are my results…
OS: 10.11.4 (15E65)
MacBook Pro (Retina, 13-inch, Early 2015)
3.1 GHz Intel Core i7
16 GB 1867 MHz DDR3
Intel Iris Graphics 6100 1536 MB
With given settings (and I used a regular keyboard to play - not Seaboard) and plugin window open:
CPU Load Meter shows anything between 60 and 75%, usually in the middle, so around 67-70.
Activity Monitor floats between 105 and 125% of CPU load (I guess that the total value is 100% times the number of cpu cores, because only then it makes sense).
Results: Very very bad, a LOT of crackling
With the plugin window closed:
CPU Load Meter possibly drops a little bit, by around 5% maybe, so it swings anywhere between 55 and 75, but often it is lower than before, mostly under 60%.
Activity Monitor shows a significantly lower numbers, between 60 and 80, usually lower than 70%.
Results: So much better, almost good enough, but still I get too many crackles to find it enjoyable, certainly not good enough for public performance - every few seconds (2-5 seconds) theres a few “artefacts”. Everytime I cmd+tab to a different window etc. there’s also a significant “breakdown” and there’s a LOT of crackling noise for a second and then everything goes back to normal.
With voices number set to 1 there are no glitches at all, I couldn't notice even a single one, CPU Load Meter shows numbers around 12-18% and Activity Monitor around 55-65% of CPU load, so very similar to 8 voices + windows closed situation. When I closed the plugin window then Activity Monitor dropped even more, to around 15-25%, but no change on CPU Load Meter in Ableton.
Since I'm back at my place: I work with audio interface now (focusrite scarlett 6i6) and it changes nothing. So I guess that there's something about my hardware that just isn't compatible with plugin's code. I understand that my report isn't very helpful, so I'll wait for other people to report similar problems and if there aren't any then some time in the future I will try to reinstall OS X clean and try again. Thanks!
Ok, I did the same for Live: only one track, animations disabled (although they don't seem to make much difference), looped noted created with piano roll, same patch selected etc. And the results are:
- 512 no problems at all
- 256 it crackles once in a while. sort of usable, but not really, because every minute or so (sometimes much less) I guess that CPU will get occupied with something slightly and the sound will break down. it's just not a stable performance.
- 128 obviously bad, but for comparison: it's better than 256 in Bitwig
Hello and thank you for all the input so far. Sorry it took me a while to respond - there's a holiday in Poland and I was away.
So, it turns out that ROLI, MPE etc. had nothing (or little) to do with it. Here's what I did: I disconnected all my controllers, I closed all the apps, restarted Bitwig with clean new project, removed unnecessary tracks, created just one with Kaivo on it, I did NOT enabled "force MPE", I disabled animations and even numbers within Kaivo settings (I also clicked a plugin size reset), Kaivo is set to MIDI protocol only (not MIDI MPE), I then created one continuous note using piano roll and looped it. I selected "agree to disagree" patch (but it's the same for others) and I just hit play with various buffer settings. I was looking at DSP graph also.
And the results are these:
- for 512 it's mostly smooth but if I do as little as to move my mouse over tray icons or anything really - it often (not always) triggers some crackling. Not usable in real life.
- for 256 it's non stop crackling, but sound is clear behind.
- for 128 crackling is so bad it affects the timbre :)
Oh, I am not using audio interface currently as I am away visiting home town for holidays. It's a built in audio card.
I'll try it in Ableton Live next and let you know (it's my default DAW really, but for recording MIDI of Seaboard performances I tend to use Bitwig 8-track).
Thank you thetechnobear. The noise I was referring to is not the "protection noise" unfortunately.
As for your test. Without MPE with default patch I can go as low as 64 samples without any artefacts (for one single continuous note). But for example "agree to disagree" pad for the same single continuous note without MPE works clean on 512 samples minimum - anything less and it gets bad.
In general for me to feel confident, play multiple notes (nothing crazy), with MPE I need to set the buffer to 1024 samples, but sadly at this point it becomes unplayable.