[PD-dev] [PD] libpd netreceive

[Thomas Grill]

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


-- 
Thomas Grill
http://grrrr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20130121/24e8feb8/attachment-0001.htm>