steve at k-hornz.de
Mon Jul 22 19:55:08 CEST 2002
günter geiger wrote:
> The problem that exists though, is that pd as a programming
> language depends on messages being synchronous with the
> signal processing, but only in few contexts, patch loading
> not being one of them.
this is perfectly ok as long as methods don't violate realtime
constraints. still, i guess that making all sent messages
return synchronously within the processing graph contributes
to pd's design being as clear and understandable as it is
i just had a thought: since audio is turned off anyway when
reading patches (correct me if i'm wrong), it might be
possible to deactivate the jack client for patch loading and
reactivate it afterwards.
> On the other hand I think I do not understand how playing in
> sample synch can be achieved by multithreading. For
> soundfile reading for example. At the end you have to insert
> a buffer at one end or the other, which will make you lose
> your sample sync, no ?
the idea is to move non-realtime tasks (such as disk access)
to separate (non-realtime) processes.
for disk streaming, you would read your data ahead of time,
buffer it and preferably transfer it to the audio thread using
lock-free ringbuffers, as done e.g. in ardour or ecasound,
such that the audio processing callback won't get blocked
under any circumstances (i think readsf~ does approximately
by 'sample synchronous' i referred to the exchange of data
generated in realtime: in jack the clients' processing
callbacks are triggered synchronously once per buffer
computation; no latency due to intermediate buffering is
introduced, just like in pd's processing of the dsp chain (the
only exception being latencies due to graph cycles, in jack
> Anyhow, I would be very interested to take a look at your
i'll package the stuff and send it to you ...
More information about the Pd-list