pd heavy preset handling (with tables)

lokki
i used this code back in the days to load 16 samples into tables on startup of a heavy program. i can simply adapt this to load only one file.
my preset-table has a format of integers between 0 and 127 (midi messages). can i still get the data from a text file via the getSamples function? or is this only working with wav files? note that i cannot try this right now, since my bela is in my atelier. or is there a similar function to getSamples to read data from a text file. either way, i don't mind what format the preset file will be in since i will only save and recall it from within heavy. so it can also be a pseudo wav file if that is the easiest solution.

char fileName[12];
 char tableName[14];
 char lengthName[14];
 for (int k = 0; k < 16; k++) {
   sprintf(fileName, "sample%d.wav", k);
   sprintf(tableName, "sample-table%d", k);
   sprintf(lengthName, "samplelength%d", k);
int sampleLen = getNumFrames(fileName);
hv_uint32_t tableHash = hv_stringToHash(tableName);
hv_table_setLength(gHeavyContext, tableHash, sampleLen); // resize the table
float * table = hv_table_getBuffer(gHeavyContext, tableHash); // once resized, get a pointer to the array
int channel = 0; // take the first channel of the file
int startFrame = 0; // start from the beginning
int lastFrame = sampleLen; // until the end of the file
getSamples(fileName, table, channel, startFrame, lastFrame);
 //optional bonus: send a message to a `[receive myTableLengthReceiver]` in Heavy with the new table length
 hv_sendFloatToReceiver(gHeavyContext, hv_stringToHash(lengthName), sampleLen);
 }

giuliomoro or i can simply divide my 0-127 range by 127 and multiply within heavy when i receive the data again. the less fuzz the better...

i will try to write the writeSamples() function and see if i can get something going :-)

giuliomoro ok, i got the reading and scaling part sorted out. that was pretty basic, since i just had to copy from the previously posted render.cpp and adjust it a bit. for the writing bit, i looked at the SampleLoader.h file to see how getSamples() is constructed. do you have any reference for the writeSamples() function i should write? who wrote the SampleLoader.h? i found this: https://github.com/erikd/libsndfile/blob/master/examples/sndfilehandle.cc but the format of the functions is quite different to what is in SampleLoader.h

or here, just for my own reference: http://www.labbookpages.co.uk/audio/wavFiles.html#writingC

ok when i change the sfinfo.format = SF_FORMAT_WAV | SF_FORMAT_FLOAT;
to: sfinfo.format = SF_FORMAT_WAV | SF_FORMAT_PCM_16;
the name is correct. however there is no data written in that case, file is 0.0kb and audacity can still not open it.

giuliomoro
thanks as always for your support!! i replaced the name variables with constants and indeed it works now, great! actually that 12 in there was a typo in the first place.

and, i got bitten by the "heavy or IDE not updating all the files it should" bug... once i deleted the whole heavy destination folder and recompiled everything the data is now correctly written out into the wav file, great! i did not have to change anything in the code...

thanks again, i will now try to implement it into my actual patch.

lokki thanks again, i will now try to implement it into my actual patch.

and it all works flawless! i was wondering in the process if it is worth the trouble to use heavy, but first of all my CPU dropped from 80 % to 28 % and second the latency is much smaller, and since this is a vocal live processor this was very important! thanks again.

ok, coming back to this...

there is a problem with my code or the way it is executed.

every now and then the presets.wav file gets garbage data when i write to it which makes the presets useless in the long run.

could it be that sometimes the data cannot be written right because it runs in the audio-thread? at this point i am writing 400 samples into a wav file and i get 14 blocks dropped when i do so. 9 out of 10 times it works but if it doesn't the generated wav file has not much to do with my presets anymore. is there a way to write the samples in an auxiliary task to avoid this problem?

i am running the system off the internal memory and also save on there, could this be the problem? (i can switch to an sdcard if that is the issue)

giuliomoro This shouldn't be a problem, unless you suddenly kill the board without shutting down gracefully. If that is the case, when the file is corrupted you'd expect it to be shorter, or empty. You should probably add a call to sync()(see man page ) after sf_close(), to ensure the file is correctly synced to disk and not stored in a buffer by the OS.

thanks for the hint, will do this! however:

the corrupted presets file is exactly the same in size but has just random 1 and even a -1 written to it.

(above is the wrong file, below a correct preset file)

i had one other suspicion. i call the libsdnfile write process immediately after i write to the table within heavy. i do this with a
[t b b] to make sure the call is after the write. however there is quite some stuff going on in the first bang, so maybe the second bang is incorrectly scheduled before everything finishes, and hence data is written to disk while the array changes which is not a very good idea. i changed this now to make sure it starts after the last write into the array. let's see if i get any more false writings...

ok, seems it is not the writing after all. i just got the bad preset loading again. (all sounds are garbled) i stopped the bela process and looked at my presets file, it was still intact. i started again, got the same garbled presets, and now saved a preset. no the file was completely useless as well. so it seems the reading (which happens in setup) sometimes fails and corrupts the data.