[PD] jack

[Miller Puckette]

Seems to me it's possible to make Pd talk to jack without any major
rewriting; simply make a library that appears from Pd to be called to
transfer samples, and appears to jack to be called to provide samples.
It would have to open a separate thread to respond to the jack calls,
and maintain FIFOs to synchronize between them.

In Windows land, the same strategy would work for making PD act as a VST
plug-in.  Needless to say, I'll try this as soon as I don't have any more
urgently needed stuff on my stack, or if someone else wants to try, be my
guest...

cheers
Miller

On Mon, Jul 22, 2002 at 07:55:08PM +0200, stefan kersten wrote:
> 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>
> 
>