# Ftgen memory allocation

**URL:** <https://forum.cabbageaudio.com/t/ftgen-memory-allocation/792>\
**Category:** Csound Noobs\
**Created:** [2 November 2017 09:42 UTC](https://forum.cabbageaudio.com/t/ftgen-memory-allocation/792 "2017-11-02T09:42:33Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Karamel1](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/karamel1/32/1680_2.png) [@Karamel1](https://forum.cabbageaudio.com/u/Karamel1)\
**Post date:** [2 November 2017 09:42 UTC](https://forum.cabbageaudio.com/t/ftgen-memory-allocation/792/1 "2017-11-02T09:42:33Z")

</div>

Hi all,

When calling twice ftgen with the same table number, does ftgen de-allocate the previously allocated table or does the code need to de-allocate it explicitely with a `ftgen -tablenumber ....` using a negative table number?  
In the Csound book, it is said that creating a table from the score with a negative number de-allocates it. Therefore I supposed that tables are never de-allocated except if explicitly requested.  
Is that right and is this also applicable to ftgen?

Thanks for help

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [2 November 2017 18:07 UTC](https://forum.cabbageaudio.com/t/ftgen-memory-allocation/792/2 "2017-11-02T18:07:26Z")

</div>

To be honest I always assumed they were simply overwritten, or resized accordingly. I would have to look at the c caring sources to be able to say for sure. I’m away at the moment but I can take a look when I get back.

---

<div class="post-metadata">

**Author:** ![t\_grey](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/t_grey/32/1234_2.png) [@t\_grey](https://forum.cabbageaudio.com/u/t_grey)\
**Post date:** [2 November 2017 23:39 UTC](https://forum.cabbageaudio.com/t/ftgen-memory-allocation/792/3 "2017-11-02T23:39:17Z")

</div>

In my experience, overwriting a table with a different sized table resulted in a crash, but I haven’t tried in a while so it might have changed or bee fixed. I think I mostly use ftgentmp for some reason I can’t remember anymore, which might also affect things…

I have an old effect I’m reworking that alters/replaces tables dynamically as you move sliders, so it’s made easily hundreds if not thousands of table changes without me noticing a memory issue. Here’s an old version of that effect if you want to play with it: [Effect: Shaped Up](http://forum.cabbageaudio.com/t/effect-shaped-up/47)

The old version was written for cabbage1, I’m about to upload an updated version to that thread that’s functionally identical to the old one but will work ok in cabbage2. I also have a newer better version in the works, but it will probably wait on further development and features of c2 before it gets released.

---

<div class="post-metadata">

**Author:** ![Karamel1](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/karamel1/32/1680_2.png) [@Karamel1](https://forum.cabbageaudio.com/u/Karamel1)\
**Post date:** [3 November 2017 08:53 UTC](https://forum.cabbageaudio.com/t/ftgen-memory-allocation/792/4 "2017-11-03T08:53:21Z")

</div>

So, I suppose that there is no arm de-allocating a table before reallocating it with a negative number.

Somehow, most of the memory problems of my synth are gone now that I am de-allocating the tables before recreating them. ( Or maybe this is a belief and it does not do anything)

```
instr	LoadSoundFile	; load sound file
        SFilePath strcpy p5
        if filevalid(SFilePath) ==1 then
             gitableOscA	ftgen	-901,0,0,1,SFilePath,0,0,0	; deallocate table first with negative number
             gitableOscA	ftgen	901,0,0,1,SFilePath,0,0,0 ; load sound file into a GEN 01 function table 
             gichansOscA	filenchnls	SFilePath ; derive the number of channels (mono=1,stereo=2) in the sound file
             giReadyOscA =	1 ; if no string has yet been loaded giReady will be zero
             gkTabLenOscA	init ftlen(gitableOscA)/gichansOscA ; table length in sample frames         	
             Smessage sprintfk "file(%s)", SFilePath ; print sound file to viewer
             prints Smessage
             chnset Smessage, "filerOscA"
        else 
            printks "File no valid \n",0
        endif
endin
```

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [3 November 2017 09:48 UTC](https://forum.cabbageaudio.com/t/ftgen-memory-allocation/792/5 "2017-11-03T09:48:10Z")

</div>

Interesting. You may be on to something. Incidentally, Cabbage overwrites previous table data each time you update the table number. I’ve never noticed any issues but I’ll take a look.

---

<div class="post-metadata">

**Author:** ![Karamel1](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/karamel1/32/1680_2.png) [@Karamel1](https://forum.cabbageaudio.com/u/Karamel1)\
**Post date:** [3 November 2017 09:56 UTC](https://forum.cabbageaudio.com/t/ftgen-memory-allocation/792/6 "2017-11-03T09:56:07Z")

</div>

Hum, from what I understood of programming,every pointer needed to be freed before being rewritten or the contrary might lead to ghost chunck of occupied memory which would never be de-allocated. This applies to all language but the ones with a garbage collector like python. But maybe I am wrong.  
But I am very happy that my stupid question helps improving cabbage and Csound.