16 messages in at.iem.pd-listRe: [PD] jack| From | Sent On | Attachments |
|---|---|---|
| smoerk | Jul 20, 2002 3:28 am | |
| Frank Barknecht | Jul 20, 2002 5:49 am | |
| stefan kersten | Jul 20, 2002 11:16 am | |
| ünter geiger | Jul 22, 2002 3:11 am | |
| Miller Puckette | Jul 22, 2002 10:51 am | |
| stefan kersten | Jul 22, 2002 10:54 am | |
| ünter geiger | Jul 22, 2002 11:05 am | |
| CK | Jul 22, 2002 11:17 am | |
| ünter geiger | Jul 22, 2002 12:14 pm | |
| CK | Jul 25, 2002 7:54 am | |
| ünter geiger | Jul 25, 2002 7:58 am | |
| stefan kersten | Jul 25, 2002 8:47 am | |
| Olaf Matthes | Jul 25, 2002 8:54 am | |
| stefan kersten | Jul 25, 2002 9:02 am | |
| Miller Puckette | Jul 25, 2002 10:21 am | |
| stefan kersten | Jul 25, 2002 11:09 am |
| Subject: | Re: [PD] jack | |
|---|---|---|
| From: | Miller Puckette (mpuc...@man104-1.ucsd.edu) | |
| Date: | Jul 22, 2002 10:51:40 am | |
| List: | at.iem.pd-list | |
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>