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) {
2013/1/21 Peter Brinkmann peter.brinkm...@googlemail.com
Hi Thomas,
There's no mailing list for libpd, but there is a forum:
http://createdigitalnoise.com/categories/pd-everywhere In any case, this
does seem like a question for pd-dev, so we're in the right place :)
About sys_microsleep, there are two potential problems that I'm concerned
about about: The first is that it might block, but that doesn't seem to be
the case since it's being called in the audio callback. The second concern
is that I'm not sure how this low-level access to network sockets might
behave on Android (which requires special permissions for internet access).
I'm expecting that it'll be okay, but we need to make sure. Please let me
know how it goes!
Best,
Peter
On Mon, Jan 21, 2013 at 6:43 AM, Thomas Grill g...@g.org wrote:
Ok Peter, let's move this over to pd-dev. There is no specific libpd
list, is it?
I have now quickly looked into what the context of the socket polling is
like in Pd.
It is even done in the audio callback (via sys_pollgui) if this is
enabled, so it can't really have serious side effects. As far as i have
seen libpd also uses a callback based approach for audio, at least for iOS.
Maybe introducing a sys_microsleep(0,1) in the audio callback does the
trick? I will test that now.
That said, i'm totally unaware of the details of other implementations.
all the best,
gr
2013/1/21 Peter Brinkmann peter.brinkm...@googlemail.com
Hi Thomas,
I have to admit that I didn't realize that netreceive requires an extra
polling step. So, I'm afraid that netreceive is currently broken.
The question is what to do about this. I took a quick look at
sys_domicrosleep and didn't immediately see how it works. I wouldn't mind
integrating it into libpd somehow, but I want to be sure that there won't
be any weird side effects. This seems slightly off-topic for pd-list. Shall
we talk about this on pd-dev?
Cheers,
Peter
On Sun, Jan 20, 2013 at 6:42 PM, Thomas Grill g...@g.org wrote:
Hi all,
i am new to libpd and i have run into problems using netreceive on ios
5.1.
While netsend works perfectly, netreceive doesn't work at all. Senders
can connect to the receiving socket, but netreceive wouldn't spit out any
data.
Looking at the code, it seems to me that the polling of the net sockets
(done in plain Pure Data in s_inter.c / sys_domicrosleep) is not called in
libpd at all. I also couldn't find a different place where this is done.
Does that mean that libpd doesn't currently service incoming socket
data?
Thanks for clarification, all the best,
gr~~~
--
Thomas Grill
http://g.org
___
pd-l...@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
--
Thomas Grill
http://g.org
--
Thomas Grill
http://g.org
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
