That's a tough one to track down. One thing I'd recommend is to reduce the complexity. Specifically, [readanysf~] is a wonderful object, but relies on many many libraries and has many layers in it. This bug could have come from any one of those libraries in addition to Pd, readanysf, etc.
For the media that you're using, I recommend converting them with 32-bit float WAVs, the internal format used in Pd. Then you can use [readsf~] or even better, load them into tables and play them with [tabplay~].
.hc
On 10/29/2012 03:35 PM, Jörn Nettingsmeier wrote:
hi *!
two days ago, my pd-based cue player (btw, new release at http://stackingdwarves.net/public_stuff/software/CueFrog/) chashed and burned during a live show. not good.
pd segfaulted while i had one six-channel instance of readanysf running and five more two-channel instances stopped, at the precise moment when i was sending a midi cc to stop the running player and another to start a new one, while i was at the same time moving a midi fader for volume control.
unfortunately, i had core dumps disabled, and as luck would have it, the crash seems impossible to reproduce without an audience of 200 and a director to go ballistic. so unless someone has an audience simulator test scaffold: what are, in your experience, the most likely causes of such sudden segfaults, and are there workarounds or defensive practices which i could implement?
i'm using the current releases of pd-vanilla, vbap and readanysf~.
in case someone feels inclined to look at my programming style and lead me back to the path of righteousness, the actual show patch i was using on top of CueFrog is at http://stackingdwarves.net/download/pd-crash.pd
looking forward to your ideas!
best
jörn