[PD] Announcing native Pd patch display in MobMuPlat Android

[Daniel Iglesia]

Hi all,

A little while ago, I released a version of MobMuPlat for iOS with native
Pd patch rendering.

https://itunes.apple.com/us/app/mobmuplat/id597679399?mt=8

Now, I'd like to announce that feature has come to Android as well!

https://play.google.com/store/apps/details?id=com.iglesiaintermedia.mobmuplat

Please let me know of bugs, incongruities, and other issues via the github
issue tracker

https://github.com/monkeyswarm/MobMuPlat/issues

or via direct email contact.


(Implementation details below, just for the curious)

I was previously asked in another list thread about the implementation,
regarding how I was not needing to attach send and receive to GUI objects.
I'd like to further explain here.

For the initial iOS release, I had created abstractions for each GUI
object, and was processing the raw Pd file as text to insert those
abstractions into the patch. However, this approach was becoming unwieldy
as I attempted to reverse engineer all the behavior of a GUI object into an
abstraction that didn't contain the GUI object itself.

So for subsequent releases, I no longer use any abstractions. I've switch
to manually inserting all the necessary send/receive objects directly into
the Pd text file. This allows the GUI object to remain in the patch. All
messages flowing _to_ the GUI object are sent to the app display layer, and
all messages flowing from the app display layer (in response to user
interaction), is sent back into the GUI object in the patch. I hope to
illustrate this below.

Here's an initial patch state.

[image: Inline image 1]

And here's what gets generated internally. "0-gui-rec" is the handle that
the app display widget is sending/receiving on.

[image: Inline image 2]

Note that there is _no_ pass-through at the app display layer, e.g.
something going to [s 0-gui-rec] will _not_ trigger an output in [r
0-gui-send].

There's still some complications, though. Atom widgets (e.g. float number
boxes) remove their inlet/outlet if it has a send/receive name. This
complicates my ability to connect to/from it. So in this case, I modify the
float box to not have internal send/receive names, which restores the
inlet/outlet, and then manually generate send/receive objects to mimic the
intended behavior.

Here's an initial state.

[image: Inline image 3]

And the post-processing state.

[image: Inline image 4]

Hope that shines some light on it!

Best, Dan

www.danieliglesia.com

www.mobmuplat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160228/6ac411f9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nativeGuiProcess2Pre.png
Type: image/png
Size: 9608 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160228/6ac411f9/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nativeGuiProcess1Pre.png
Type: image/png
Size: 13989 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160228/6ac411f9/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nativeGuiProcess2Post.png
Type: image/png
Size: 15753 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160228/6ac411f9/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nativeGuiProcess1Post.png
Type: image/png
Size: 22603 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160228/6ac411f9/attachment-0007.png>