5 messages in at.iem.pd-listRe: [PD] Feature suggestion: pd non-r...| From | Sent On | Attachments |
|---|---|---|
| Johannes Taelman | Nov 8, 2002 3:05 pm | |
| Krzysztof Czaja | Nov 14, 2002 4:04 am | |
| Krzysztof Czaja | Nov 14, 2002 5:31 am | |
| Miller Puckette | Nov 14, 2002 8:38 am | |
| Johannes Taelman | Nov 14, 2002 10:09 am |
| Subject: | Re: [PD] Feature suggestion: pd non-realtime | |
|---|---|---|
| From: | Johannes Taelman (joha...@rug.ac.be) | |
| Date: | Nov 14, 2002 10:09:33 am | |
| List: | at.iem.pd-list | |
Hi Miller and list,
From: "Miller Puckette" <mpuc...@man104-1.ucsd.edu>
... aah, nobody answered because it's such an important question...
I was afraid that I was the only one to consider it an important feature...
I'm planning to add ANOTHER flag, like -nosound, but also disabling waiting for the system clock (as Pd now does.)
That's the way I'd expect it to work.
At the same time I want to introduce the modifications needed to allow Pd patches as VST plugins. As it looks right now that should appear in 0.37 (i.e., I don't want to break 0.36 open now that it mostly works..)
This sounds like a GREAT plan! In the case of VST-plugging non-realtime would probably work 'out-of-the-box' by using the plugin in a batch processor, eg. cubase 'mixdown', wavelab 'apply' or whatever.
On Thu, Nov 14, 2002 at 01:04:46PM +0100, Krzysztof Czaja wrote:
Measuring with [bang~]->[t b b]->[realtime]->[number] may be deceptive. If you look at an average of [realtime]'s output, then it will show 1.4 (at 44.1kHz).
Right!
thanks all, j#|@