seems absolutely fine as far as Ive seen… we really aren’t sending that much data
exactly, the idea is I don’t want to change anything in the mother patch or ‘synth’ patch at all , I want it to run out of the box 
(we later could consider a concept of service discovery if we wanted this to be more user friendly, but honestly, this started just as a tool for me… and I thought I might as well share it (but was a little unsure, as its not really ‘user friendly’)
what nice about this approach is, its pretty much 99% the same as running on the Organelle, since not only is the patch talking OSC, but its talking to mother.pd, so all the graphics mode etc work too.
so I find it really hand for developing patches
background:
Im also developing cross-platform externals , so Im doing most of that dev on the mac, to test on the Organelle, i was having to do initial testing on macOS with ‘dummy patches’ , then check it in, build the external on organelle, run the organelle patch, debug that there - so this along with other ‘tools’ , helps to just smooth the process a bit.
ok, Im not going to get into really how to run this too much, as I don’t have the bandwidth to support this.
but hopefully if others start using, then others can dive in to help … its not complete once you’ve got it working
configuring mac for using mother.pd
anyway some tips on how to get mother.pd working on macOS when using, this… so our goal is to run PD like this on the mac:
/Applications/Pd-0.47-0-64bit.app/Contents/Resources/bin/pd -path ~/Library/Pd/Organelle ~/Documents/Organelle/mother.pd Basic\ Poly/main.pd
obviously your paths may differ…
to get this to work, the main thing is putting macOS version of all the externals mother.pd needs into ~/Library/Pd/Organelle , which are
override.pd
routeOSC.pd_darwin
unpackOSC.pd_darwin
packOSC.pd_darwin
udpsend.pd_darwin
udpreceive.pd_darwin
tb_peakcomp~.pd_darwin
vnu~.pd_darwin
override.pd , I copied from the Organelle (@oweno, we should probably have the externals directory in Organelle_UI)
the OSC/udp externals, are freely available, I compiled these from mrpeach which Id installed via Deken.
tb_peakcomp~ , I got from here , (if you dont have this , you’ll get no audio 
)
vnu~.pd_darwin, you’ll need to compile from here, but if you dont have it , you’ll just not get the audio meters at the top of the display
so takes about 5 minutes to setup, but then your desktop is pretty much the same as running on the Organelle
(of course, if the patch uses externals you will need to compile/source these for macOS, but thats the same as before when using desktop mother)
I guess I (or someone) could package all this up, but as above, I don’t really want to get into support on this..
advance usage:
you’ll get a warning about not being able to read from /tmp/patch …
if you need a patch to be 100% correct, you should create a symbolic link from the patch directory to /tmp/patch before your start the patch… but most patches do not need this.
(if you have patches trying to access /usbdrive inform the patch developer to stop doing it, its unnecessary )
taking further
ok, i dont really have time to do much on this , but if someone wanted to take this further, this could be taken such that end-users could use this as an alternative to desktop-mother.pd , what would be needed is quite simple
- build/collect externals needed by mother.pd , and place in a package (basically what ive described in text above)
- do for all windows/mac/linux … OscProxy is cross-platform
done
- service discovery… its possible to change OscProxy such that it ‘announces’ itself on a subnet.. this would means a user could simply run the host on Organelle, and another one on the desktop, and they would ‘see each other’ and cross connect… i.e. zero configuration.
advanced future: Organelle mother host, currently assumes one client/patch on localhost, port 4000.
we could create a service discovery protocol external for Pd, so the patch announces to mother host where it can be contacted (including host:port). this would be a useful extension, as not only would it allow for remote patches, but opens up the potential of running multiple patches, since the 4000 port is not hard-coded
