TL;DR: Use PdWrapper.pd. It exists for a reason.

If you don't use PdWrapper, a patch that works on your computer is not going to work (neither GUI message sending nor networking) on your mobile device. MobMuPlat 1) does not use network messages to communicate between the UI and the patch (they are the same app, so there's no need), and 2) handles networking at the app layer, not in pd objects. The point of PdWrapper is to simulate that interaction for you, so that the patch on your computer works on mobile.

So in both cases, your mobile patch should not have any netreceive/netsend objects. Look at the example patches. The networking example patch, has the simplest example that covers both these issues. It receives GUI interaction via [fromGUI] and it sends/receives network data via [receive fromNetwork] and [send toNetwork]. Go to the MobMuPlat networking options to specify the IP address and port numbers.

Pdwrapper.pd is for pd vanilla, not pd-extended.

Hi, could you please post your patch and the full error dump here (or at https://github.com/monkeyswarm/mobmuplat/issues)

Also, are you loading the patch with a custom interface, or by itself (to use the native pd gui)? If the latter (which is always a bit dicey), I'd try the former and see if it loads correctly that way. If so, then it's some case that I haven't handled correctly.

Forgot to document this, will do so....

[key]/[keyup] don't work with libpd-based apps (since they go through the Tcl/Tk layer on the desktop app, I believe).

Instead, MobMuPlat has a workaround:

[receive fromSystem]
|
[list trim]
|
[route /key]

Note that this may or may not cover non-ASCII-range key values successfully...let me know.

1. No, externals cannot be included unless they are built into the project at compile-time (i.e. from the source). The public versions of MobMuPlat are currently vanilla-only.
   (Note that the "built-in" externals, fiddle~, etc, are available).

2. Yes, see the "MMPExamples-Networking.mmp" example, which takes slider touch and sends out an OSC network message. Go to the MobMuPlat Network settings to specify a destination IP address and port number.

Then have your computer listen on that port (using UDP). In pd on your computer, that would be

[ listen XXXXX (
|
[netreceive -u -b]
|
[oscparse]

(but if you look at PdWrapper.pd, you'll see my custom solution for getting the OSC messages in a preferable format (with the slashes intact) rather than what [oscparse] does)

1. Recording to RAM has an upper limit on how large of a buffer you can allocate (I don't recall what the limit is), whereas recording to disk is contrainted only by available disk space. Recording to disk should not interrupt audio unless you are simultaneously reading/writing a lot to/from disk (or otherwise overworking the audio thread).

2. Not really. At the moment, PdParty has, in addition to pd vanilla, the externals at https://github.com/danomatika/PdParty. MobMuPlat only has the built-in vanilla externals (fiddle~, etc). There's no way to "drop in" new external objects (because iOS does not allow dynamic loading).

3. LANdini, Ping & Connect, (and, to my knowledge, Abelton link), and merely sending out a ping to other devices over multicast, all require a local network, meaning you'd have to carry around a router and have people connect to that. Otherwise, if over cell data (3G, etc), you'd have to program (in native app code) some sort of shared time (e.g. using NTP, network time protocol, which in my experience works well and will give you sub-second precision across multiple devices set to go off at the same time)

4. Pd vanilla only for both PdParty and MobMuPlat

5. There's a working example on www.mobmuplat.com, go to "rough doc" link.

He posts the patches & interfaces for download, see the links in a few of these posts:
http://www.otemrellik.com/tag/mobmuplat/

Do you have an iPhone 6S or newer? Apple no longer supports variable sampling rates on the device speaker, it is hard-wired to 48K. However, if you plug in headphones, you can usually change the sampling rate at that point.

Have you tried it on other hardware? The Moto E is an inexpensive phone. I've tested your patch on a Nexus 6 running Lollipop and a Nexus 7 (2013) running Marshmallow, and it seems to work fine on both.

You might try changing the sampling rate down to 32000 or 22050 and see if you have enough processing power for that.

In my experience, another big issue (for Android) is latency, the Nexus' latency is not great, perhaps the Moto is better?

Other than the "built-in" vanilla externals (fiddle~, etc), you won't be able to add other pd objects (unless you recompile MobMuPlat from source).

BTW [netreceive] actually does work within a MobMuPlat patch, but it's not recommended as it is not as robust as using the built-in networking (via [send toNetwork] and [receive fromNetwork]), since it can cause a crash that leaves a port open (I should try to fix that...).