Ftgen memory allocation

[Karamel1]

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

[rorywalsh]

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.

[t_grey]

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: 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.

[Karamel1]

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

[rorywalsh]

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.

[Karamel1]

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.