[PD] jack

[stefan kersten]

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
currently.

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
that, too).

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
propably too).

> Anyhow, I would be very interested to take a look at your
> solution.

i'll package the stuff and send it to you ...

<sk>