sounds like a cool project @widdly
p.s. /tmp/patch… be aware, Im talking with owen about extending/changing this… basically as id like to separate data/preset storage from the patch directory.
interesting comments on the multi core aspect, not something I’m tackling at the moment, though its is something ive considered a little on how id tackle… one though I had thought was to ditch mother host from launching the PD application, and instead have mother host use libpd, so this would enable it to track multiple patches correctly… basically acting as a PD host (something like the way a DAW hosts VSTs) … but thats a non-trivial task.
generally though, I think Im trying to solve a similar issue as you, but in a different way…
In no way am I trying to clone an Organelle (no need I have 2 
) on other platforms,
rather I see the problem as one of hardware abstraction in patches
The issue I have, is I don’t think PD patches should be written so that they hard code the control interface… imagine if VSTs assumed a certain display size, or having 4 knobs… no, I patches should abstract this, and then it is the ‘controller’ that should have code written that can ‘render’ that patch in the most appropriate way.
again the VST example is very relevant… whilst they can render their UI, they also present a unified parameter list… and this is how things like automation are possible.
(amusingly, MEC, which oKontrol is part of, also runs as a VST, so theoretically, I can allow you to control oKontrol parameters from your pi/Organelle from the mec VST running on your PC/mac in a daw )
… its also why I think OSC is useful, so not only is there a PD external, and C++ api for interfacing, but also a ‘wire interface’.
(btw: im happy to talk to other developers about the osc messages, and how they might be improved)
why is this only coming up now?
I don’t know, I was genuinely surprised when I first looked (2 months ago?) at PD that there was not some kind of standardised parameters/preset system, that all patches used.
but I think the reason is, most PD patches were written for PC/Mac with screens, but here - we are interested in headless patches, patches controlled either remotely, or from midi devices, etc etc, perhaps this use-case is just now relevant to more people on different ‘micro’ platforms.
(as a side note, any talk I’ve made of a oKontrol touchscreen interface for the Pi actually has had a lukewarm reception, its a nice to have, but musicians seem more interested in getting physical control integration)
of course, my approach requires patch developers to adapt, and to ‘buy in’, which i will only be able to convince if they see big advantages e.g. easy to implement, and nice interface for users … so thats my first target.
fortunately, as I developed a whole bunch of Mutable Instrument patches which seem quite popular, I can use those as these guinea pigs… to let developers and users alike see the advantages (or not).
if they think it looks cool, and they like , they can use … if not, then perhaps it will inspire something else, this is what open source is all about (for me)
anyway, Im excited by the response so far… seems others also think this is an important piece of the puzzle for these kind of hardware setups 
anyway, less talk , more coding!
p.s. another side of this , for me, is its not just about PD!
e.g. after then next Axoloti firmware release, I plan to build an oKontrol interface into axoloti, so that Axoloti’s parameters are exposed onto the same infrastructure… so then ‘controllers’ build to use oKontrol to control PD patches, will then be able to control axoloti patches as well…
as I said, its all about abstraction
