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?