Cabbage Logo
Back to Cabbage Site

Ftgen memory allocation

#1

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

#2

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.

#3

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

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.

Effect: Shaped Up
#4

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
#5

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.

#6

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.