Closed ahihi closed 2 years ago
ok, i got a little suspicious about the single broken WAV i have in my library, pointed out in the message:
WARNING: File reading failed for path: '/Users/ahihi/SyncBig/sc/dirt/samples/nab/narayanbreikki-129.wav'
i removed it, and sure enough, the code now works as expected... i still don't understand why or how it fails completely on what should be just a warning though. maybe memory corruption?
in case anyone wants to experiment with this, the broken file is available here: https://owo.uwu.fi/narayanbreikki-129.wav
The error message is really strange indeed, I also don't understand how ~dirt
could become nil as a buffer loading fails.
I wonder if it would be better to really throw errors when something like file reading goes wrong, instead of just warning. @yaxu what do you think?
i am trying to add some of my own WAV metadata parsing to latest develop
and seeing this weird behavior again - SuperDirt object looks fine inside the function that sets it up, but becomes nil when returned to the caller. im at a complete loss on how to debug this..
SuperDirt object looks fine inside the function that sets it up, but becomes nil when returned to the caller.
You mean after your set up, ~dirt == nil
?
yes, very similar situation to the original post. in fact i noticed i had a new invalid wav file in my library and that was again causing the problem.
so i looked into the error handling a bit and after a lot of confusing experimentation i noticed that this line in readWithInfo
probably should be prefixed with a ^
? it seems the intention is to return nil on failure, but the current code returns a Buffer with nil members which has just been free
d. this sus buffer passes the notNil
check and i guess something breaks down the line.
i added that ^
and now the ~dirt
returned by my function looks fine even with the invalid file causing a read fail warning! (i prefer this behavior over throwing)
also, this try
seems wrong (no catch function, try
ed function takes an error arg?) but im not sure whether it affects any of the above.
anyway, yay progress! :) i can test a bit more and make a PR later this week.
i'm using supercollider 3.12.2 on macos 10.14. the following is a simplified version of my startup code:
this works fine with SuperDirt 1.7.2, but fails with 1.7.3:
i'm very confused by the debug print output
which suggests that i have a valid SuperDirt object up until the
~makeDirt
function returns, but the return value then somehow becomes nil?i notice that if i remove the second
loadSoundFiles
call, the code again works correctly and i get the expected debug outputany idea what's going on?