I don't know what your actual patch looks like, but if it's just about sending some messages at the beginning, you can use the "-send" command line option:
-send "msg..." -- send a message at startup, after patches are loaded "msg..." can be any number of messages delimited by semicolons, e.g. "foo 1 2 3; bar 10; baz 5;" Christof > Gesendet: Montag, 27. Januar 2020 um 11:40 Uhr > Von: "Christof Ressi" <christof.re...@gmx.at> > An: "Charles Z Henry" <czhe...@gmail.com> > Cc: Pd-List <pd-list@lists.iem.at> > Betreff: Re: [PD] netreceive vs mrpeach/udpreceive in batch mode > > Hi, > > > I'm guessing that mrpeach/udpreceive and netreceive have different > > polling behavior that can explain this, but I don't see it yet. Is > > there anyone reading, who's dealt with this issue before? > > They actually use the same polling mechanism. I tried to receive OSC messages > with [mrpeach/udpreceive] while running it batch mode and it doesn't work, > just like I expected. Are saying this works for you? I would be quite > surprised... > > As the ticket on sourceforge mentions, there's no explicit call to > sys_pollgui() in batch mode *) - which by the way is a misnomer because it > polls *all* sockets -, so I don't see how [mrpeach/udpreceive] could work > under such circumstances. > > > I have been writing a patch to send messages to/from a subprocess in > > batch mode. First, I wrote the patch with mrpeach's > > udpsend/udpreceive and got it working. It's just a simple handshake: > > I think the real problem is that you're using batch mode for the wrong job. > In batch mode, Pd will run as fast as possible to get a certain task done. If > you wait for incoming network traffic while in batch mode, you're just busy > waiting and wasting lots of CPU cycles. Just use Pd in realtime mode instead! > > Or is there a specific reason why you think you need to receive messages > while running in batch mode? > > > Here the cpu load goes to 100% > > This is totally expected, as you want to run your task as fast as possible. > > Christof > > *) to be correct, there is a hidden call to sys_pollgui() if there are more > than 5000 clock timeouts in a given scheduler tick (see sched_tick()) > > > Gesendet: Montag, 27. Januar 2020 um 02:20 Uhr > > Von: "Charles Z Henry" <czhe...@gmail.com> > > An: Pd-List <pd-list@lists.iem.at> > > Betreff: [PD] netreceive vs mrpeach/udpreceive in batch mode > > > > Hi list, > > > > I have been writing a patch to send messages to/from a subprocess in > > batch mode. First, I wrote the patch with mrpeach's > > udpsend/udpreceive and got it working. It's just a simple handshake: > > > > the toplevel process starts listening on port 16000 for a message [1 > > 1(. When it receives that message, it sends back a message [1 > > subprocess#( to localhost port 15999. > > > > The subprocess starts up, listens on port 15999 and sends a message [1 > > 1( to localhost port 16000. When it gets a message [1 n( on port > > 15999, it outputs n as the subprocess #, and opens a new port 16000+n > > (and closes 15999). > > > > This was fine, except udpsend/receive pairs exchange binary numbers > > (0-255). It will work, but it doesn't make the patches as easily > > readable. It will still be possible to pass integers larger than 255 > > with a little patching, but some flexibility would be nice. > > > > I thought "netsend -u"/"netreceive -u" would make a good replacement > > with text instead. > > > > It runs fine during the first part of testing with the GUI. I test > > "-nogui". Also fine. Then, "-batch" added. Here the cpu load goes > > to 100% (which didn't happen with mrpeach udpsend/receive). I'm able > > to strace and see the first message [1 1( sent. Then, the process > > keeps on going but doesn't receive any further UDP messages. > > > > I'm able to find a sourceforge ticket from 2012: > > https://sourceforge.net/p/pure-data/bugs/943/ > > and basically, I'm looking for the same usage case which is batch mode > > processing under supervision from another Pd process. > > > > I'm guessing that mrpeach/udpreceive and netreceive have different > > polling behavior that can explain this, but I don't see it yet. Is > > there anyone reading, who's dealt with this issue before? > > > > Chuck > > > > > > > > _______________________________________________ > > Pd-list@lists.iem.at mailing list > > UNSUBSCRIBE and account-management -> > > https://lists.puredata.info/listinfo/pd-list > > > > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
