# Processing a long duration File with FluCoMa in SuperCollider

**URL:** <https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442>\
**Category:** Getting Started and Wayfinding\
**Created:** [November 12, 2024, 6:20am UTC](https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442 "2024-11-12T06:20:48Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![areacode](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@areacode](https://discourse.flucoma.org/u/areacode)\
**Post date:** [November 12, 2024, 6:20am UTC](https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442/1 "2024-11-12T06:20:48Z")

</div>

Hi there -

I’m attempting to analyze a longer duration file in FluCoMa, using SuperCollider - but it seems to lock up for quite some time.

I know that with the Plotter example, it is shown to use an “s.sync” every 100 frames or so - but even this, at least how I am using it, does not seem to expedite the process.

I’m wondering if there is a way to do this that runs a little faster.

Thanks!

```auto
analysis = {|bufPath, onThresh = -22, offThresh = -30|

var indices = Buffer(s);
var display_buffer = Buffer(s);
concat_buf = Buffer(s);
FluidBufCompose.processBlocking(s,bufPath,destination:display_buffer);

FluidBufAmpGate.processBlocking(s,display_buffer,
		indices:indices);

indices.loadToFloatArray(action:{
    arg fa;
    var current_frame = 0;
    fa = fa.clump(2);
    fa.do{
        arg arr, i;
        var startFrame = arr[0];
        var numFrames = arr[1] - startFrame;
       "%\tstart: %\tend: %".format(i,startFrame,numFrames).postln;
        FluidBufCompose.processBlocking(s,display_buffer,startFrame,numFrames,destination:concat_buf,destStartFrame:current_frame);
        current_frame = current_frame + numFrames;
		if((i%100) == 0){s.sync};
    };
​
    FluidBufCompose.processBlocking(s,concat_buf,destination:display_buffer,destStartChan:1);

		~x = concat_buf;
​
});
};
)

```

---

<div class="post-metadata">

**Author:** ![tedmoore](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tedmoore/32/439_2.png) [@tedmoore](https://discourse.flucoma.org/u/tedmoore)\
**Post date:** [November 12, 2024, 11:04am UTC](https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442/2 "2024-11-12T11:04:05Z")

</div>

Hi @areacode ,

Can you give us a bit more info?  
How long is the file?  
Stereo or mono?  
How long is it taking?  
How many slices are being discovered by FluidBufAmpGate?  
What do you mean by “lock up”?  
Does it ever complete?

Thanks!

T

---

<div class="post-metadata">

**Author:** ![areacode](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@areacode](https://discourse.flucoma.org/u/areacode)\
**Post date:** [November 12, 2024, 5:17pm UTC](https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442/3 "2024-11-12T17:17:14Z")

</div>

Hi @tedmoore -  
It’s a stereo file, 24 minutes in duration.  
It seems to crash at around 600 slices - it disconnects from the server, after extended periods of yellow idling. It doesn’t ever complete.  
I’m not sure if this is unusual - or if the normal protocol is to chunk out larger files before trying to process them, so any insight would be helpful.

---

<div class="post-metadata">

**Author:** ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)\
**Post date:** [November 13, 2024, 2:03pm UTC](https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442/4 "2024-11-13T14:03:25Z")

</div>

Is it stalling in the `fa.do{...}` loop? If so, then one way to make this more efficient would be to pre-allocate `concat_buf` to the size you’re going to need, otherwise the server is having to re-allocate and copy the buffer however many hundred times.

That will involve a little bit more language-side work before you launch the loop, but seeing as you have the float array in the language anyway, it’s not so bad. E.g, between `fa.clump(2)` and `fa.do` you could say

```js
dur = fa.collect{|arr| arr[1] - arr[0] }.sum 
concat_buf = Buffer.alloc(s, dur ...

```

---

<div class="post-metadata">

**Author:** ![areacode](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@areacode](https://discourse.flucoma.org/u/areacode)\
**Post date:** [November 13, 2024, 6:13pm UTC](https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442/5 "2024-11-13T18:13:08Z")

</div>

Wow - this works incredibly well. Thank you.

---

<div class="post-metadata">

**Author:** ![areacode](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@areacode](https://discourse.flucoma.org/u/areacode)\
**Post date:** [November 24, 2024, 5:43am UTC](https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442/6 "2024-11-24T05:43:45Z")

</div>

In a scenario where the final buffer size might be un-calculated - is there any any advantage/possibility to simply “overshooting” by specifying a larger buffer than expected? Is there a simple command for trimming the excess after it has been filled?

---

<div class="post-metadata">

**Author:** ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)\
**Post date:** [November 24, 2024, 3:05pm UTC](https://discourse.flucoma.org/t/processing-a-long-duration-file-with-flucoma-in-supercollider/2442/7 "2024-11-24T15:05:53Z")

</div>

Yeah, if you don’t know the final size then this can work. IIRC, you can trim with `FluidBufCompose` by setting the `source` and `destination` to the same `Buffer`