I'm further developing [neuralnet] to include variational autoencoders. Trying to train it on audio, I want to be able to read audio files without using Pd's [readsf~]. I have managed to read unsigned 16-bit WAV files inside the object, but when I'm trying to store the values to the object as a training dataset, Pd crashes, and I think this is related to memory reallocation.
The code can be found here https://github.com/alexdrymonitis/neuralnet/tree/develop
You'll need some audio files in a directory named "recordings", which should be in the "examples" directory (in the GitHub link the "recordings" directory doesn't exist, because it would be empty, and Git won't let you create an empty directory, if I'm not mistaken). Follow the steps in the 05-audio_variational_autoencoder.pd example, and Pd should crash. I think this happens when the `store_audio_training_sample()` function is called, in line 4407 in neuralnet.c.
Any help greatly appreciated.
On 19/03/2025 11:14, Alexandros Drymonitis wrote:
I'm further developing [neuralnet] to include variational autoencoders. Trying to train it on audio, I want to be able to read audio files without using Pd's [readsf~]. I have managed to read unsigned 16-bit WAV files inside the object, but when I'm trying to store the values to the object as a training dataset, Pd crashes, and I think this is related to memory reallocation.
i haven't checked the code, but three things that come to my mind are:
- learn (basic) usage of a debugger. the simplest one os of course the printf-debugger, but it only gets you so far. otoh "gdb" is a mighty beast, but for getting a basic backtrace of a crashed program you only need to learn 3 or so commands.
- for memory issues, learn to use valgrind. it will tell you all kinds of memory problems in your code (and in libraries used, so there might be a number of false positives, but the output is readable enough to quickly find any problems related to *your* code)
needless to say, that you shouldn't only *learn* how to use these tools, but also actually *use* them (in the case of valgrind, I would say there's practically no need to "learn", as usage is dead simple; you just run "valgrind pd" instead of "pd"). i exclusively use these tools from the cmdline, but there might be graphical front-ends, idk.
- finally, i honestly believe you are suffering from NIH-syndrome. you really should rethink your design: rather than spending time on debugging what went wrong with reading unsigned 16bit WAV files, you could just use tables pre-populated by [soundfiler] - and hey, you would get support for SND, AIFF, CAF and even text files *for free*, and not only 16bit but also 24bit and 32bit. and with the use of 3rd party externals, there would be FLAC And mp3 and ogg and whatnot support.
gfmdsar IOhannes
On 3/21/25 10:38, IOhannes m zmölnig wrote:
- learn (basic) usage of a debugger.
the simplest one os of course the printf-debugger, but it only gets you so far. otoh "gdb" is a mighty beast, but for getting a basic backtrace of a crashed program you only need to learn 3 or so commands.
I've been using gdb, but TBH, I couldn't understand much from what I was getting, other than that it was some memory reallocation that was causing the crash.
- for memory issues, learn to use valgrind.
it will tell you all kinds of memory problems in your code (and in libraries used, so there might be a number of false positives, but the output is readable enough to quickly find any problems related to *your* code)
It didn't occur to me to use valgrind, should have...
- finally, i honestly believe you are suffering from NIH-syndrome.
you really should rethink your design: rather than spending time on debugging what went wrong with reading unsigned 16bit WAV files, you could just use tables pre-populated by [soundfiler] - and hey, you would get support for SND, AIFF, CAF and even text files *for free*, and not only 16bit but also 24bit and 32bit. and with the use of 3rd party externals, there would be FLAC And mp3 and ogg and whatnot support.
I was thinking that [soundfiler] wouldn't work with long audio files (around 15 minutes). First of all, I was wrong. Second, even if this was the case, I should have split my audio files to shorter chunks and indeed use [soundfiler]. Instead I indeed suffered from NIH-syndrome and preferred to go down the rabbit hole of trying to read audio files inside my object. I'll go with this option eventually.
Thanks for the tips.
On Mar 21, 2025, at 3:43 PM, Alexandros Drymonitis adrcki@gmail.com wrote:
On 3/21/25 10:38, IOhannes m zmölnig wrote:
- learn (basic) usage of a debugger.
the simplest one os of course the printf-debugger, but it only gets you so far. otoh "gdb" is a mighty beast, but for getting a basic backtrace of a crashed program you only need to learn 3 or so commands.
I've been using gdb, but TBH, I couldn't understand much from what I was getting, other than that it was some memory reallocation that was causing the crash.
It usually helps to step through the frame and find which pointer ends up being NULL when it shouldn't. At least that's how I use lldb in a simplistic way Also make sure you build Pd with debug symbols enabled, usually something like
./configure --enable-debug CFLAGS=-g
- finally, i honestly believe you are suffering from NIH-syndrome.
you really should rethink your design: rather than spending time on debugging what went wrong with reading unsigned 16bit WAV files, you could just use tables pre-populated by [soundfiler] - and hey, you would get support for SND, AIFF, CAF and even text files *for free*, and not only 16bit but also 24bit and 32bit. and with the use of 3rd party externals, there would be FLAC And mp3 and ogg and whatnot support.
I was thinking that [soundfiler] wouldn't work with long audio files (around 15 minutes). First of all, I was wrong. Second, even if this was the case, I should have split my audio files to shorter chunks and indeed use [soundfiler]. Instead I indeed suffered from NIH-syndrome and preferred to go down the rabbit hole of trying to read audio files inside my object. I'll go with this option eventually.
[soundfiler] might work, but it's also nice not to have to use an intermediate table and the resulting memory.
Maybe it makes sense to expose the internal Pd soundfile reading API to externals to avoid people having to implement this themselves?
-------- Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/