On Tue, Sep 10, 2013 at 2:01 PM, Kjetil Matheussen k.s.matheussen@gmail.com wrote:
Since most processors don't flush denormals and non-numbers to zero by default, Pd classes have to deal with it in some selective way. If all math objects (signal objects in particular) would flush those generally undesired numbers to zero, that would make Pd slower. The compromise is to flush problematic values wherever they cause a serious problem, like recycling NaN's. In your [vd~] example the NaN seems to result in an illegal pointer value. The same issue might happen in other table reading objects with index inlets ([tabread], [tabread4~], [cyclone/poke~]). Did you try that?
Thank you! That's what I wanted to know. I'll provide a more thought-through patch for vd~, and perhaps tabread4~ and poke~ as well.
The trouble with vd~ was a real world example (provided by a user) that made radium (with now has pd embedded) crash. He couldn't continue working on his song, since pd patches are saved inside radium song files, and radium crashed as soon as he tried to load the song.
Oops, that is a nasty case. I was just about to say: it is an open question to what extent Pd must be idiot-proof. After all, Pd can be considered a computer language, a patch can be considered a program, and the programmer has some responsibility too. Why should one send NaN as an index value or delay time to some object? Well, maybe because Pd is often used for wild experiments, like the example case illustrates. Pd should not crash on bugs in a patch I guess.
Katja