lokki o. 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.

can you describe what is in the generated "corrupted" wav file? Try and save several copies of the file without changing the preset of the content, so that you would expect it to generate exactly the same file over and over again. Set aside a "good" one, and a "corrupted" one.
First off, check if the size is exactly the same in both cases. Then use hexdump to print a hex dump of the files and see where the differences are. You would expect that the header of the two .wav files would be the same, and that there is some difference in the data part, perhaps.

lokki could it be that sometimes the data cannot be written right because it runs in the audio-thread?

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.

        this gives you an idea of the difference between close() (which implies flush()) and the data being actually written to disk, which should happen normally after a while, or can be forced withsync().

        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.

        alt text

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

            and... i found the bug.

            i realised that when the presets where garbled this message was printed on the bela console:

            File samples scale = 16.2277

            which of course made my presets values to large by an amount of 16.227

            i now changed the offending line and sure enough it works again :-)

            if (subformat == SF_FORMAT_FLOAT || subformat == SF_FORMAT_DOUBLE) {
		double	scale ;
		int 	m ;

		sf_command (sndfile, SFC_CALC_SIGNAL_MAX, &scale, sizeof (scale)) ;
		if (scale < 1e-10)
			scale = 1.0 ;
		else
		//	scale = 32700.0 / scale ;
		scale = 1.0 ;
		cout << "File samples scale = " << scale << endl;

		for (m = 0; m < frameLen; m++)
			tempBuf[m] *= scale;
	}

            so it seems that the signal max calculation is sometimes way off in getSamples()

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

              this suggests it's something wrong on the heavy/C++ side of things then.

              lokki 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 don't see why this would be a problem. The execution is single-threaded, so there is no way I can think of that you would be able to get a non-deterministic behaviour because of concurrency. Is it possible that there is some non-deterministic behaviour in the patch? I.e.: are you sure that you are sending the message to write the table to file only when the table is in a valid state?

              Another test to try and localise the issue would be to dump a regular C array instead of whatever you get from heavy.

                    giuliomoro Another test to try and localise the issue would be to dump a regular C array instead of whatever you get from heavy.

                    see my previous post, the issue was with the getSamples()scaling function...

                      lokki so it seems that the signal max calculation is sometimes way off in getSamples()

                      Yes, I removed it in more recent versions of SampleLoader.h: https://github.com/BelaPlatform/Bela/issues/542

                      I am a bit confused as to why and how, if the issue was in getSamples(), it managed to affect the written file and not the one you read.

                          giuliomoro I am a bit confused as to why and how, if the issue was in getSamples(), it managed to affect the written file and not the one you read.

                          yes this was because i saved a preset when i already had the garbled file loaded which of course did also create a garbled preset file on writing (since it wrote back the bad loaded data). at that point i did not know that it was the reading bit and assumed (since i wrote the writing part) that that had to be broken...

                            giuliomoro Yes, I removed it in more recent versions of SampleLoader.h

                            whoops, that is what you get for not updating regularily. sorry for the noise then...

                              or for not following this recommendation:

                              giuliomoro float formats do, and my hint would be: stay away from them unless you actually need them

                              Funny thing: in that sentence I was referring to libsndfile's pitfalls when using floats, and it turned out we had some on our side as well 🙂