Hello,

I've been working for a few months on a patch that got more complicated than I had planned, and I finally decided to split it into subprocesses to avoid audio clicks when UI elements refresh. In the past I've done it with 2 separate pd processed and osc calls between both, but I'd like to try with [pd~] instead (which I've read about bit never actually used for real).
So as a first step I'm just trying to load my whole complicated patch inside a [pd~] subprocess (with DSP on in both of course) using a simple

[pd~ start mybigpatch.pd(
|
[pd~ -ninsig 8 -noutsig 2]

It works with a simple patch in the same folder, however with the big one, the subprocess starts, loads the libraries, and immediately closes, showing only pd~: No such file or directory in the parent process' Pd console window.
I get no more details when adding -d 4, -stderr, -verbose or even -noloadbang (in case it's the patch initiation that failed).
My "big patch" will call many abstractions, initiate arrays, soundfilers and load text files into [text] objects so there are quite a few possibilities for not finding files - however the exact same patch starts perfectly from the same folder. Using the whole path to the patch in [pd~ ( also doesn't help.

Are there any known limitations to what [pd~] can or cannot do compared to the main parent pd process?

Thanks!

I think I finally figured it out!
Well, not sure it solves all my problems, but at least here is a limitation of pd~: midi inputs and outputs (obviously)! There were a few of those in one of the libraries called by mybigpatch.pd (r_cycle).

So here is my way around it, in case it might help others:

• In the main patch, capture notein and send [notein $1 $2 $3( to [pd~]:
  
• in the pd~ subprocess, capture the incoming in an abstraction ./myfolder/notein.pd:
  
  and replace all instances of [notein] with [./myfolder/notein]
• similarly for noteout, an abstraction ./myfolder/noteout.pd to use in the pd~ subprocess:
  
  and replace all instances of [noteout] with [./myfolder/noteout]
• in the main patch, replace noteout with [r noteout]:
  
• and the same thing with ctlin, ctlout, bendin, bendout, midiin, midiout, etc.

And the command line magic trick (that it took me a while to figure out) in order to replace all this easily in all pd files:
$ sed -i 's+\(touchin\|polytouchin\|bendin\|notein\|ctlin\|midiin\|midiout\|noteout\|ctlout\)+'./myfolder/'&+' *.pd, which will prepend any instance of notein & co with ./myfolder/.

Improvement suggestions are of course welcome.
Cheers!

@zigmhount I have not used [pd~] in anger. In the help file there are two switches..... -pddir and -schedir....... that seem to set resource paths......... but it doesn't say what are the defaults........ or whether there are defaults.
There is a note in the manual for pd 0.51-2 "Better support for white space in file path to pd, especially for pd~ object."
So it does seem that pd~ handles its paths independently (from pd).
And it is running in the /extra/pd~ folder unlike the pd process which is in the pd/bin folder........ which seems to be an odd choice that is likely to mess up the search paths.
David.

@whale-av Hmm thanks, this sounds like I might actually be better off with running parallel pd processes right from a shell script and communicating via netsend (this laptop has only 2 cores, so audio processing is all running in the same patch anyway, and controls+GUI in the other), rather than trying hard to get it working with [pd~] and possibly hit some more undocumented limitations later on...
I guess I'll try a bit more, and let's see where I end up

Not being familiar with [pd~] this all seems surprising.

[pd~] should just start another independent instance of Pd, load a patch and provide communication between the instances.

So the default paths of Pd should also apply to the new instance.

Sends and receives should not work between instances.

pd-test.zip