Hi list, Would it be possible to add a flag to [pd~] to keep the parent instance from blocking?
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.
-Jonathan
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. 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 Pd.
cheers Miller
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 blocking?
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.
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 Pd.
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 to know 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.
-Jonathan
cheers Miller
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 blocking?
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.
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list