You can create applications that directly run PD patches, by using a library called libPd. the advantage is you can then integrate your application into the PD patch directly.
all in much the same way as you can write a DAW to host a VST, and then it’s the DAW that can control the VST.

So… rather than ‘mother host’ starting PD it would be the thing hosting the patches… this opens many possibilities.


I think I understand, I’ll try again tomorrow.
What kind of possibilities?

lots… just off the top of my head:

  • improved performance…
    currently messages go from the STM controller to (serial link) mother host to (via osc) pd… but if the patch was within the mother host, then these messages would not have to be transmitted via OSC to PD, they would just be passed ‘in memory’.
    thats less cpu for ‘the patch/pd’ and mother host.
  • integration
    the host could handle the audio directly, e.g. for monitoring/gain control for audio input, or gain control on output. unified midi device selection.

generally, it allows the mother host to have more direct control over the environment the patch lives in, rather than having to leave it to mother.pd, or how linux is configured - so that might actually help support as well.

however, this is a non-trivial change, so its more an idea I have for the future… something when I have time to try out to see what extra ‘complications’ it throws into the mix.

for now, Ive other plates spinning in the air, so this will have to wait :wink:

1 Like

Those are some intriguing possibilities! a while ago I had something setup with libpd. It was nice to have everything under the same roof… wondering how patching would work, if you had the whole setup using libpd it would only work for ‘playing’ patches. to edit them you’d need regular Pd, or maybe some way to attach Pd gui to libpd process?

yeah, for a gui, you’d have to run PD…
but this is not too dissimilar to what we have now, a non-gui and gui mode… just the non-gui is implemented differently.
to be clear, I see this as running libpd as an option, whilst retaining the current ability to kick off PD and other programs. (of course we would hide the ‘technicalities’ from end-users)

(btw: you might want to split this discussion out from this thread, going a bit OT :wink: )