Hi Peter,
at least on iOS, the whole thing boils down to the patch below.
I added two initialization functions to libpd_init, the first sys_findprogdir for finding the pd binary directory (actually to initialize the symbol sys_libdir which can also be done manually), and second sys_startgui to initialize the data structures for networking. That this fundamental functionality is mangled with GUI-related code is not pretty and should certainly be refactored (in Pd proper).
The polling happens in the PROCESS macro, after audio has been processed. I think using a sleep time of 0 it should be non-blocking, but it would definitely be better (in sys_domicrosleep) to avoid calling the system function Sleep (only matters for WIN32) for timeouts of 0. Maybe Miller should review that.
I am not sure whether using memory management functions in an audio callback is a problem - it shouldn't, as Miller certainly had a look at that. This happens because the incoming networking data is stored in dynamically allocated binbuf structures.
That's my report - it works for me now.
all the best,
gr~~~
----------
--- a/libpd_wrapper/z_libpd.c
+++ b/libpd_wrapper/z_libpd.c
@@ -20,6 +20,8 @@
#include "g_all_guis.h"
void pd_init(void);
+void sys_findprogdir(char *progname);
+int sys_startgui(const char *guipath);
t_libpd_printhook libpd_printhook = NULL;
t_libpd_banghook libpd_banghook = NULL;
@@ -65,7 +67,9 @@ void libpd_init(void) {
sys_nmidiout = 0;
sys_time = 0;
pd_init();
+ sys_findprogdir(""); /* set sys_progname, guipath */
libpdreceive_setup();
+ sys_startgui(sys_libdir->s_name); /* start the gui */
sys_set_audio_api(API_DUMMY);
sys_searchpath = NULL;
}
@@ -128,6 +132,7 @@ static const t_sample sample_to_short = SHRT_MAX,
} \
} \
} \
+ sys_microsleep(0); \
return 0;
int libpd_process_short(int ticks, short *inBuffer, short *outBuffer) {