[PD] pd~ clock
jancsika at yahoo.com
Sun Apr 5 05:47:44 CEST 2015
On 04/04/2015 12:45 AM, Miller Puckette wrote:
> I think it's possible but would require lots of changes - perhaps to the point
> that it would be more appropriate to make an entirely separate object.
Ah, ok. That certainly makes sense. Maybe something like [pd], if the name
[pd] weren't already taken.
> It wouldn't make sense to send audio back and forth, and the synchronization
> is most of the complexity in pd~.
> Meanwhile, if we're just piping Pd messages (as in netsend/netreceive) into
> and out of a sub-process, that might be useful with other programs besides
Hm... that scares me. If there's an internal Vanilla object which can only
spawn more Pd's then I'm brave enough to open patches from the
user list. However, if there's a Vanilla object which can spawn arbitrary
programs on my machine then it's no longer worth the risk to me.
Also, I think that would harm portability. Since most users don't run their
patches on all supported platforms at once, it's very difficult for them
when their patching choices chain them to a particular OS. But as long as
the core objects have the same functionality on all platforms, the users can
patch with impunity.
> On Fri, Apr 03, 2015 at 05:23:26PM -0400, Jonathan Wilkes via Pd-list wrote:
>> Hi list,
>> Would it be possible to add a flag to [pd~] to keep the parent instance from
>> It'd be like starting another Pd instance manually and using
>> netsend/netreceive to communicate between them, except modular and portable.
>> Gem + audio comes to mind. But also offloading heavy (and often
>> inefficient) work into the other process. For example, if you know that
>> generating some pitch data takes an average of ten seconds, but you've got a
>> minute before the section of the piece where you need the data.
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list