Hello! First time poster here.

I'm looking in to the possibilities with sending signals between instances of PD.
My 'dream' scenario would be to have a setup something like this:

One "control" branch which handles most interaction with the real world, presets, signal routing and conditioning, etc. this would optimally be running at 96k (0.5x192k) sample rate.

One "sound generation" branch. Basically oscillators and some sound shaping, running 192k.

One "filtering and output" branch, running at 192k but with upsampling to 2x for the filter section. The "baseline" level of this branch would be hosting some envelope generators and the audio output.

So what I'm hoping for is to:
Send signals from both "real world" and the "control" branch, directly into "sound generation" and "filtering and output" in parallel. Having them arrive simultaneously at each destination.
This, while the audio would be running in a straight series manor:
Generation->Filtering->Output. (Hopefully not landing in the 192k level of the filtering branch before being upsampled and filtered..)

So...
Would this be possible? Maybe its just as simple as using sends and throws? Or are we forced to build in levels, so to say? Having control signals go through "Sound Generation" before heading on to "Filtering and output".
The documentation in how this feature works seems like a well kept secret I'm trying to find examples how others handle these things but I've been coming up short.

A bonus question, simple yes or no
Is communicating either control or audio, through the PD~ object, faster than the other?

I hope I spark some inspiration in someone who might put my spinning head to rest! I'm looking forwards to sharing this project when it's done, I think i've managed to get a very pleasing sound. The main reason for the layout I'm pondering is basically to have "note" and "velocity" sent directly to both "sound generation" and "filtering and outout", to minimize latency between keydown and envelope trigger. Maybe I'm just being stupid

Cheers!

@Booberg No you can open at least 64 ports..... maybe more..... so....
[netreceive -u 10000]
[netreceive -u 10001]
..
..
..
[netreceive -u 10063]
and their corresponding [netsend -u] in the control patch.

10000 to 10063 are the port numbers and it is best to make them big.
25 would clash with email for example.
But what do you mean by controller values at audio rate? Do you mean 192000 messages / second ........ or sent as audio signals?
David.

@whale-av that doesnt sound so scary, will definitively try it for signals that need to traverse both sub-processes. When i say audio rate i mean audio signal. I basically use audio for most data to get smooth value changes using the good old "[pack f ms]-[line~]". And since i have quite a number of modulation sources and destinations it is pretty much obligatory to convert most parameters to audio eventually anyways.

@Booberg You will have to sent small data control packets through [netsend] and then do [pack] [line~] in the audio instance.
To send the 30 odd outputs of [line~] through 30 streaming objects like [ggee/streamout~] could be heavy.
But again, you cannot know until you try.
David.

Well yes, this is what i figgured. I was only really planning on sending the actual synthesized audio through that method but even so, it seems a shaky foundation. I'll stick to the straight forwards way of using the inlets and outlets of the pd~ objects and will have to have the audio snake its way through the sub processes. It feels a bit like a wild goose chase right now, because the laptop im designing this on only has 2 cores and this layput is so much worse for preformance on this machine but, as the Rpi has 4 cores i believe it could be worth it in the end. A valuble experiment if nothing else!

Im using [prepend 'control value']-[send 'subprocess'] to get the values to where they want to go for now and it's proving to be a pretty neat way of routing things as i can then tap those 'lists' from [return subprocess] into a single send object that will send it to whatever parameter name is attached to each value. So i dont have to have a separate send object for each control parameter aswell. Just a nice, slight, convenience I did have to use [reverse] to get the correct bang order for that.

Ill just squeeze in a question here too.
Can you open a subprocess with -nogui? Its not an accepted flag for the pd~ object from what i can se. What I forgot to try today was to type it in in the startup message i send to the object, maybe that could work?

@Booberg It looks like it is going well.
If you need to keep it vanilla you can replace [reverse] with some maths........

I think you will need to trawl the forums for -nogui on the RPI.
I know I have seen plenty of posts about problems but I don't know whether they were solved.
The -nogui flag should go in File Preferences startup startup-flags (the box at the bottom).
It is then applied as Pd starts and as [pd~] is spawned by Pd maybe it will then be applied to that sub-process.
David.

@whale-av Will go on a quest for -nogui but it's for the near future i think. And I have to have GUI on the main process, so we'll se how that goes.
The reverse i use (ELSE) is actually vanilla (i think?). And it reverses the order of a list! But now when i look into it deeper i se it's waay overcomplicated for just reversing a list of 2 elements.
I did this now instead, same basic idea you posted

Thanks so much for the feedback and help!

@Booberg Very good.
Just slightly simpler....... and doesn't need to know whether floats or symbols...
David.

@whale-av Oh hell yes Thanks again

Couldn't find this info before so I'll post it here:
[pd~ start -nogui blabla.pd(

Will launch a headless subprocess. (osx 10.13)