# CPU Spikes with fl.read~ **URL:** \ **Category:** Bugs\ **Created:** [11 November 2019 15:04 UTC](https://framelib.discourse.group/t/cpu-spikes-with-fl-read/50 "2019-11-11T15:04:25Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![d.murray-rust](https://yyz2.discourse-cdn.com/free1/user_avatar/framelib.discourse.group/d.murray-rust/32/35_2.png) [@d.murray-rust](https://framelib.discourse.group/u/d.murray-rust)\ **Post date:** [11 November 2019 15:04 UTC](https://framelib.discourse.group/t/cpu-spikes-with-fl-read/50/1 "2019-11-11T15:04:25Z")
### Summary: I like grains 🙂 and with @o.green have been making a replacement for the GMU GMEM granulator using framelib. Mostly working! I’m getting horrible CPU spikes - going from ~3% to \>40%, and glitching audio playing from all other sources. I _think_ this is only inside an M4L environment, but still narrowing down. ### FrameLib Version: _pretty sure_ it’s the [Alpha-2.5](https://github.com/AlexHarker/FrameLib/releases/tag/Alpha-2.5) release - happy to try a more recent one if that sound promising. ## Environment Details (Max/SC/Whatever): macOS Mojave 10.14.6, 2.6 GHz Intel Core i7, 32 GB 2400 MHz DDR4 Live 10.4.1b1 Max 8.1.0 ### Steps to reproduce (Provide patch/code if possible): There’s a folder with the patches in here: [rgr.grains.zip](https://framelib.discourse.group/uploads/short-url/eWaaV2t7F5DZvSzH25araxn4MeY.zip) (146.7 KB) (also a github: [https://github.com/mo-seph/rgr.bufgrains](https://github.com/mo-seph/rgr.bufgrains)) If I open the help patch, I can set it to play a 4s grain every 2 seconds, and that’s fine (although definitely not free). If I use the MinimalLiveGranulator.amxd in the examples folder to do the same think (2000ms timing, 2.0 fill) then the cpu goes wonky. It’s generally when the grain kicks off, but not every time. ### Actual Result: CPU goes spiky and all the audio goes glitchy ### Expected Result: Buttery smooth delicious grainy goodness ### Logs/Other We (well, @o.green ) had a look with Instruments from XCode, which traced it to the fl.read~ object. We had a thought that it could be an interpolation thing - I thought that moving from default `hermite` to `linear` had helped, but it appears to still be an issue. Audio settings in Live in case it helps… ![image](https://global.discourse-cdn.com/free1/uploads/framelib/original/1X/15c10a37a132f84f338fbdfe784880963b025977.png) ---
**Author:** ![o.green](https://yyz2.discourse-cdn.com/free1/user_avatar/framelib.discourse.group/o.green/32/29_2.png) [@o.green](https://framelib.discourse.group/u/o.green)\ **Post date:** [12 November 2019 12:38 UTC](https://framelib.discourse.group/t/cpu-spikes-with-fl-read/50/2 "2019-11-12T12:38:07Z")
Having looked closer at this, and talked a bit with @d.murray-rust, I’m not convinced this is a bug so much as the consequence of our naïve design, although the more pronounced badness in Live is troubling. I’ll start a new topic about what a better design might be, but being able to spread the load more predictably so that fl doesn’t have to do all the work for big-ass grains all at once. How to achieve this in fl is another matter… ---
**Author:** ![a.harker](https://yyz2.discourse-cdn.com/free1/user_avatar/framelib.discourse.group/a.harker/32/21_2.png) [@a.harker](https://framelib.discourse.group/u/a.harker)\ **Post date:** [20 November 2019 14:17 UTC](https://framelib.discourse.group/t/cpu-spikes-with-fl-read/50/3 "2019-11-20T14:17:18Z")
If you are playing always at one speed you could turn interpolation off, but I think here the time constraints are what cause the spiky processing. I’m interested in looking further when I have a moment in order to see if things can be improved here. ---
**Author:** ![d.murray-rust](https://yyz2.discourse-cdn.com/free1/user_avatar/framelib.discourse.group/d.murray-rust/32/35_2.png) [@d.murray-rust](https://framelib.discourse.group/u/d.murray-rust)\ **Post date:** [3 December 2019 22:56 UTC](https://framelib.discourse.group/t/cpu-spikes-with-fl-read/50/4 "2019-12-03T22:56:15Z")
Grand! Yes, I could see turning off interpolation and playing just at one speed, but for general purpose graining, I think that’s where approximately 0.75 of the fun is.