For my personal education Tim, what are the "design decisions" that will never allow Pd to become a very good latency system?
pd is written as a single threaded application, if you read the pd code, you can see this everywhere ... the main pd thread does everything ... audio io, dsp computation, soundfile loading, object generation, gui communication, midi io, messaging ... basically everything.
but this is the contrary, how the audio hardware of all modern audio apis (jack, asio, coreaudio, portaudio, possibly alsa) works. the sound card sends an interrupt to the os, the driver calls a function in the program that should send/receive the audio data...
my approach for devel was to use this callback to drive the dsp computation, but to keep the system in sync, i have to lock the global pd mutex. so basically all functions that are run, while the global pd mutex is locked, should be executed, without locking the system for a too long time ...
cheers ... tim