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.brinkmann@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 gr@grrrr.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.brinkmann@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 gr@grrrr.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://grrrr.org
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-- Thomas Grill http://grrrr.org