hi miller ...
well, i think, these are two different issues ... after doing some tests during the last few days, i think, it's more a problem about having both high and low priority messaging ... and thus, only functions that are realtime safe should be allowed as clock callbacks ... otherwise, it would bind the control rate to the hardware buffer size for my asynchronous scheduler ... running not realtime safe functions might cause jack to kick pd from the dsp graph... but for now, this is a user bug :-/ not realtime-safe functions should either run in a helper thread or use the idle callbacks to run at lower priority ...
Here's another idea I'm thinking about that might be useful in this situation... I'm thinking of having a version of switch~, which never runs DSP except when you 'bang' it. This way, a block of DSP analysis or anything else could be included within a message; in fact, several of them could, and they could be interspersed with other message processing.
i like this idea ... it would make it easier to adapt pd to apply a dsp graph to a buffer, so it would be possible to do non-realtime stuff like with vasp ... one could even write a wave editor with pd :-)
cheers ... tim