[PD] New "native" Pd GUI support in MobMuPlat

[Daniel Iglesia]

I'm glad you asked! It's done in a slightly convoluted, potentially
fragile, possibly un-scalable way.

When a user loads a .pd file, pre-proccessing is done on the .pd text to
generate _two_ new .pd files, one for execution, and one for display The
two communicate with each other.
This split is done at:
https://github.com/monkeyswarm/MobMuPlat/blob/master/MobMuPlat-iOS/MobMuPlat/PdGui/MMPPdPatchDisplayUtils.m#L16

1) The "engine" patch is the patch that is actually opened by libpd and
generates audio. The processing replaces each gui object with a Pd
abstraction I made (termed a "shim" in the code) that has a send/receive
relationship (with an auto-generated handle) with the MobMuPlat- layer GUI
code.
So a line (this is the toggle in the "MMPExamples-NativeGUI.pd" file).
#X obj 253 440 tgl 45 0 /demoToggleSend /demoToggleReceive
I'm_using_send_and_receive
becomes
#X obj 253 440 MMPPdGuiFiles/MMPPdGuiShim 15-gui-send 15-gui-rec
/demoToggleSend /demoToggleReceive;
"15-gui-send" and "15-gui-receive" are the handles for send/receive with
the user-visible gui object.
Note that existing send/receive behavior is kept intact (with
/demoToggleSend and /demoToggleReceive)
There's a few flavors of this shim (in
github.com/monkeyswarm/MobMuPlat/tree/master/MobMuPlat-iOS/MobMuPlat/PdGui):
a main one for most GUI objects, a special one for a "bang", and a special
one for a message object.

2) The "GUI" patch is a simpler process, it just, for every GUI object,
sets the send/receive handles to the same auto-generated handles generated
for the matching "engine" shim that should communicate with it. After
processing, this pd patch is then read and rendered to native-app-layer GUI
widgets.

I've tested this to work for using the "internal" (object property)
send/receive labels, attaching to send/receive objects, using "set",
one-to-many and many-to-one communication. However there's probably some
use case I've overlooked (or some fun way to make it stack overflow when it
shouldn't). Let me know...!

Separate questions for everyone:
1) you may notice that the current version does not render connection
lines. While the patch text lists all the connections (and inlet/outlet
indices for them), the app doesn't know how many inlets/outlets each object
has. I haven't delved too deeply for it yet, but is there an interface
somewhere that will return that information? e.g. here's an atom line for
an object and its parameters, tell me how many inlets/outlets. If so, then
connection lines could be rendered correctly. (Without it, I could still
render conneciton lines, but if there are empty inlets/outlets after a
connection then they would not be shown.)

2) Is showing the full set of patch objects (and, eventually, connection
lines) even desirable? (Rather than just rendering the gui objects). I'm
thinking of an option that would switch their display on/off. (But leave
GUI objects, including message boxes)

Thanks for input, Dan I.


On Thu, Jan 7, 2016 at 10:55 PM, Dan Wilcox <danomatika at gmail.com> wrote:

> How are you doing this?
>
> --------
> Dan Wilcox
> @danomatika <https://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
> On Jan 7, 2016, at 9:19 AM, pd-list-request at lists.iem.at wrote:
>
> - Unlike PdParty/PdDroidParty, you don't need to define send/receive
> values for every GUI object. Just drop in your PureData patch, with normal
> object connections, and it should work. (send/receive communication should
> also still work as well).
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160108/018a21a7/attachment.html>