Hi Following up the thread about the DSP recompilation internals, it's even clearer that there are sometimes good reasons to do a 'dsp 0, dsp 1' cycle to force DSP graph recompilation, for instance to apply it only once when it would otherwise occur many times.
Unfortunately, depending on the currently used audio backend, turning dsp off often also disables the audio backend. Turning dsp back on and thus the audio backend has several side effects. Enabling the audio backend takes time, which means a 'dsp 0, dsp 1' cycle leads to a drop out that otherwise might not occur. Also, when using ALSA I often experience that Pd is not able to grab the device when turning DSP on. When performing a cycle, this sometimes results in Pd being disconnected from the backend. On the other hand, when using JACK, Pd stays connected to the JACK server, even when DSP is off. Only when using JACK, patches can use optimizations for dynamic patching, but not when using ALSA or MMIO on Windows (I don't know how ASIO and CoreAudio on OS X behave). I'd welcome if Pd would behave the same regardless of backend currently used. I'm not proposing Pd should stop disconnecting from the back-end. The fact that the 'dsp 0|1' message does two things at the same time is unfortunate (and it used to control _only_ the DSP off in earlier versions). How about introducing a new message to Pd for the sole purpose of connecting and disconnecting the audio backend? 'audio 0|1' or even 'dac 0|1' 'adc 0|1' to allow enabling input and output separately? After all 'dsp 0|1' is a misnomer for what it currently does. I wouldn't mind if the checkbox in Pd's main window would still toggle them all, but as a Pd programmer I regard it as an important feature to be able to control the DSP separately. Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
