On Thu, 3 Nov 2005, Piotr Majdak wrote:
Do I understand it correctly:
- calling outlet_float(), a depth-first handling of all objects attached to
this outlet is triggered?
yes
If yes, what must be guarrantied to avoid clicks:
- tha handling of _all_ messages of _all_ objects in pd must be completed
within one sample block?
To avoid clicks, the handling of messages should leave enough CPU power to the DSP often enough so that buffers can be sent to the soundcard. This depends on your settings for latency.
If you set the latency at the minimum possible, then the handling of the sample block in DSP _plus_ the handling of all scheduled t_clocks for that sample block must be done within the duration of one sample block, e.g. 64/44100 of a second. (I'm not even including messages from the GUI here)
If the latency is not set at minimum, then you have more headroom, as the jobs assigned to one block can spill over the time allocated to another block. This is the difference between "logical time" and "physical time".
A t_clock is what drives [metro], [line], [delay], [pipe], etc. The handling of a t_clock event includes the handling of all messages sent from those handlers, recursively, depth-first. This does not include messages which are delayed for later blocks.
What is the difference between the pd-devel and the 0.39.1? Is there a readme/howto I could read before trying the pd-devel version?
Relative to this question, I think that there is no difference. There is a plan to make DSP run in a separate thread, but I don't think that's been coded yet.
For devel_0_39 you will need to have "scons" installed. I don't think there's such a README, but doing "scons --help" will give you a list of compile-time options you may want to try, such as accelerated FFT (FFTW), accelerated DSP (SIMD), threaded soundfiler, etc.
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada