Re: [PD] Audio delay by symples (for comb filter)

2020-01-27 Thread i...@hansroels.be


I also needed a delay in samples and so I made an abstraction in Pd 
vanilla, delaying a signal with x number of  samples; for example a one 
sample delay is [delaysam 1]

I think this is the correct way of doing this without needing externals...
Hans

On 1/25/20 9:16 PM, Alexandre Torres Porres wrote:
cyclone/delay~ and else/ffdelay~ also allow for delay lines defined in 
samples (or ms)


but this can also be done in vanilla like people said (though somewhat 
inconvenient)


cheers

Em sáb., 25 de jan. de 2020 às 15:33, Ingo > escreveu:


Thanks guys!

[zexy/z~] looks exactly like what I'm looking for!

Ingo


> you can just use [delwrite~] + [delread~], but you have to make
sure that
> they are scheduled in the right order, see
"G05.execution.order.pd" in
> "doc/3.audio.examples". Also, you have to convert from samples to
> milliseconds.
>
> For convenience, I often use [z~] from zexy, which is a delay
line in a
> single
> object, with the delay time given in samples.
>
> Christof
>
>
> > Hi everybody!
> >
> > I'm planning on delaying a bandpass filter by samples to
create a comb
> > filter effect.
> > Is this possible or can it be done only by audio blocks?
> >
> > If it is possible which object(s) would I use?
> >
> > Thanks
> > Ingo






___
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



--
#N canvas 308 1008 450 311 10;
#X obj 79 47 inlet~;
#N canvas 101 1214 450 210 delay-write 0;
#X obj 63 15 inlet~;
#X obj 64 149 outlet~;
#X obj 122 95 delwrite~ \$0-delaysample 1000;
#X connect 0 0 2 0;
#X connect 0 0 1 0;
#X restore 80 91 pd delay-write;
#N canvas 787 998 349 300 delay-read 0;
#X obj 63 15 inlet~;
#X obj 65 205 outlet~;
#X obj 157 46 inlet~;
#X obj 64 148 +~;
#X obj 157 81 vd~ \$0-delaysample;
#X connect 0 0 3 0;
#X connect 2 0 4 0;
#X connect 3 0 1 0;
#X connect 4 0 3 1;
#X restore 79 250 pd delay-read;
#X obj 79 285 outlet~;
#X obj 305 114 \$1;
#X obj 302 23 loadbang;
#X obj 332 77 samplerate~;
#X obj 305 52 t b b;
#X obj 332 99 / 1000;
#X obj 305 153 /;
#X obj 378 183 print;
#X obj 305 189 pack 0 30;
#X obj 305 214 line~;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 4 0 9 0;
#X connect 5 0 7 0;
#X connect 6 0 8 0;
#X connect 7 0 4 0;
#X connect 7 1 6 0;
#X connect 8 0 9 1;
#X connect 9 0 10 0;
#X connect 9 0 11 0;
#X connect 11 0 12 0;
#X connect 12 0 2 1;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] netreceive vs mrpeach/udpreceive in batch mode

2020-01-27 Thread Christof Ressi
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" 
> An: Pd-List 
> 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


Re: [PD] Audio delay by samples (for comb filter)

2020-01-27 Thread IOhannes m zmoelnig
On 27.01.20 11:29, i...@hansroels.be wrote:
> 
> I also needed a delay in samples and so I made an abstraction in Pd
> vanilla, delaying a signal with x number of  samples; for example a one
> sample delay is [delaysam 1]
> I think this is the correct way of doing this without needing externals...

kind of.

- using [$1] can give you all kinds of nasty surprises, as you can e.g.
use [delaysam samplerate~]. i'd rather go for [float $1] instead.
- debugging printout (and a fan-out!) should be removed
- why do you use [vd~]? do you need fractional sample-delay (the answer
might well be "yes")? if not, than [vd~] is just taking more CPU-power...
- why do you ramp to the target-delay with [line~]? since you cannot
change the delay after the instantiation, i would rather have it jump to
the target delay immediately.

gfasdrm,
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] netreceive vs mrpeach/udpreceive in batch mode

2020-01-27 Thread Christof Ressi
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" 
> An: "Charles Z Henry" 
> Cc: Pd-List 
> 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" 
> > An: Pd-List 
> > 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


Re: [PD] Audio delay by samples (for comb filter)

2020-01-27 Thread Ingo
Thanks Hans and IOhannes!

I'll take a look at this as well but so far [zexy/z~] looks best to me.

Ingo


>> I also needed a delay in samples and so I made an abstraction in Pd 
>> vanilla, delaying a signal with x number of  samples; for example a one
>> sample delay is [delaysam 1]
>> I think this is the correct way of doing this without needing externals...
>> Hans


> -Original Message-
> From: Pd-list [mailto:pd-list-boun...@lists.iem.at] On Behalf Of IOhannes m
> zmoelnig
> Sent: Monday, January 27, 2020 2:02 PM
> To: pd-list@lists.iem.at
> Subject: Re: [PD] Audio delay by samples (for comb filter)
>
> On 27.01.20 11:29, i...@hansroels.be wrote:
> >
> > I also needed a delay in samples and so I made an abstraction in Pd
> > vanilla, delaying a signal with x number of  samples; for example a
> > one sample delay is [delaysam 1] I think this is the correct way of
> > doing this without needing externals...
>
> kind of.
>
> - using [$1] can give you all kinds of nasty surprises, as you can e.g.
> use [delaysam samplerate~]. i'd rather go for [float $1] instead.
> - debugging printout (and a fan-out!) should be removed
> - why do you use [vd~]? do you need fractional sample-delay (the answer
> might well be "yes")? if not, than [vd~] is just taking more CPU-power...
> - why do you ramp to the target-delay with [line~]? since you cannot change
> the delay after the instantiation, i would rather have it jump to the target
> delay immediately.
>
> gfasdrm,
> IOhannes






___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] pd~ binary for max/msp

2020-01-27 Thread cyrille henry



Le 26/01/2020 à 17:56, Miller Puckette via Pd-list a écrit :

I was doing that for a while but stopped (it was a lot of trouble tracking all
the changes in MacOS and Max at the time; perhaps this is easier now).  I
won't be able to get to a Mac with Max until later this week, but if nobody
else can do it first I can give it a try.


thanks! That would be nice.


It's a fun object - you can pretend to be using Max but do the heavy lifting
in Pd - you can use GEM, etc., too.)

that's the aim, since I don't know any other way to do heavy lifting in max. ;-)

cheers
Cyrille



cheers
Miller

On Sun, Jan 26, 2020 at 11:58:37AM +0100, cyrille henry wrote:

Hello,
Does anyone know where I can find the pd~ object compiled for max/MSP on OSX?

I don't have any apple computer, nor max/MSP, but I have to work on a project 
that should run on this configuration.
pd~ source code is made to be compiled for max, so I hope I can use it but 
can't find any binary online.

thanks
Cyrille



___
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


Re: [PD] Audio delay by symples (for comb filter)

2020-01-27 Thread William Huston
I have built a comb filter (actually a flanger) using
a combo of [delwrite~ foo] and a series of [vd~ foo]s
using an LFO which is phase-displaced across the different [vd~]s.

Can anyone tell me what is the best resolution I can get
with this combo? It it less than a per-sample resolution?

Can I build this system using something other than [vd~]
to get better resolution?

Thanks.
BH

--
William Huston:  williamahus...@gmail.com
Binghamton NY

*Public Service Mapping / Videography / Research / Education / Safety
Advocacy*
Blog  -- Facebook
 -- Twitter
-- Youtube

* -- Podcast Blog *
*Document collections*: VirtualPipelines
 -- BHDCSDimockArchive

*Please support my work! -- *TinyURL.com/DonateToBillHuston





On Mon, Jan 27, 2020 at 5:30 AM i...@hansroels.be  wrote:

>
> I also needed a delay in samples and so I made an abstraction in Pd
> vanilla, delaying a signal with x number of  samples; for example a one
> sample delay is [delaysam 1]
> I think this is the correct way of doing this without needing externals...
> Hans
>
> On 1/25/20 9:16 PM, Alexandre Torres Porres wrote:
>
> cyclone/delay~ and else/ffdelay~ also allow for delay lines defined in
> samples (or ms)
>
> but this can also be done in vanilla like people said (though somewhat
> inconvenient)
>
> cheers
>
> Em sáb., 25 de jan. de 2020 às 15:33, Ingo  escreveu:
>
>> Thanks guys!
>>
>> [zexy/z~] looks exactly like what I'm looking for!
>>
>> Ingo
>>
>>
>> > you can just use [delwrite~] + [delread~], but you have to make sure
>> that
>> > they are scheduled in the right order, see "G05.execution.order.pd" in
>> > "doc/3.audio.examples". Also, you have to convert from samples to
>> > milliseconds.
>> >
>> > For convenience, I often use [z~] from zexy, which is a delay line in a
>> > single
>> > object, with the delay time given in samples.
>> >
>> > Christof
>> >
>> >
>> > > Hi everybody!
>> > >
>> > > I'm planning on delaying a bandpass filter by samples to create a comb
>> > > filter effect.
>> > > Is this possible or can it be done only by audio blocks?
>> > >
>> > > If it is possible which object(s) would I use?
>> > >
>> > > Thanks
>> > > Ingo
>>
>>
>>
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>
> ___pd-l...@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


Re: [PD] Audio delay by symples (for comb filter)

2020-01-27 Thread Christof Ressi
[vd~] has sub-sample accuracy, using 4-point interpolation, just like 
[tabread4~]. Actually, the new name of the object is [delread4~] ;-)


Christof

On 27.01.2020 19:22, William Huston wrote:

I have built a comb filter (actually a flanger) using
a combo of [delwrite~ foo] and a series of [vd~ foo]s
using an LFO which is phase-displaced across the different [vd~]s.

Can anyone tell me what is the best resolution I can get
with this combo? It it less than a per-sample resolution?

Can I build this system using something other than [vd~]
to get better resolution?

Thanks.
BH

--
William Huston: williamahus...@gmail.com 
Binghamton NY

*Public Service Mapping / Videography / Research / Education / Safety 
Advocacy*
Blog  -- Facebook 
 -- Twitter 
-- Youtube 
*-- 
Podcast Blog 

*
*Document collections*: VirtualPipelines 
 -- BHDCSDimockArchive 

*Please support my work! -- *TinyURL.com/DonateToBillHuston 



**




On Mon, Jan 27, 2020 at 5:30 AM i...@hansroels.be 
 > wrote:



I also needed a delay in samples and so I made an abstraction in
Pd vanilla, delaying a signal with x number of  samples; for
example a one sample delay is [delaysam 1]
I think this is the correct way of doing this without needing
externals...
Hans

On 1/25/20 9:16 PM, Alexandre Torres Porres wrote:

cyclone/delay~ and else/ffdelay~ also allow for delay lines
defined in samples (or ms)

but this can also be done in vanilla like people said (though
somewhat inconvenient)

cheers

Em sáb., 25 de jan. de 2020 às 15:33, Ingo mailto:i...@miamiwave.com>> escreveu:

Thanks guys!

[zexy/z~] looks exactly like what I'm looking for!

Ingo


> you can just use [delwrite~] + [delread~], but you have to
make sure that
> they are scheduled in the right order, see
"G05.execution.order.pd" in
> "doc/3.audio.examples". Also, you have to convert from
samples to
> milliseconds.
>
> For convenience, I often use [z~] from zexy, which is a
delay line in a
> single
> object, with the delay time given in samples.
>
> Christof
>
>
> > Hi everybody!
> >
> > I'm planning on delaying a bandpass filter by samples to
create a comb
> > filter effect.
> > Is this possible or can it be done only by audio blocks?
> >
> > If it is possible which object(s) would I use?
> >
> > Thanks
> > Ingo






___
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


___
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] RPi 3B+ and PD-L2Ork

2020-01-27 Thread Paddy Burke
Hi,

I am trying to install PD-L2Ork on the Rpi 3B+. I have tried
numerous images and numerous PD L2Ork download methods with no success. The
PDPI disk image on the PD-L2Ork website will not boot for me. I mostly get
unmet dependencies errors from .deb packages, both downloaded and compiled.
If I run *sudo apt-get -f install *to fix any dependencie errors it prompts
me to uninstall PD-L2Ork. I have tried so many things I think trying to
troubleshoot each method would be very laborious. Does anyone know of a
working method to get PD-L2Ork woking on the Rpi 3B+.

Thanks
Paddy
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] netreceive vs mrpeach/udpreceive in batch mode

2020-01-27 Thread Charles Z Henry
Thanks for your replies, Christof

On Mon, Jan 27, 2020 at 4:40 AM Christof Ressi  wrote:
>
> 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 think I was unclear--as I'm editing the test patch to compare
udpsend/netsend, the key difference I'm finding is how the process
gets started from pd~
and it looks like I was wrong about this being true batch mode.
When pd~ starts up a new subprocess with "-batch", it suppresses the
GUI as expected, but it also starts the new process with "-schedlib"
which substitutes for the subprocess scheduler behavior.

> > 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?

I'm looking at long-duration signals analysis on command from a
real-time process, and I'd like that analysis to run with minimal
disruption to the real-time process.
At first, I was just buffering signals in, but decided to try using
shmem to copy tables back/forth.  That requires some coordination
between the processes to know when to read from shmem.  Messages can
be sent to a subprocess from a parent--but I had to start using
udpsend to send messages back.

That's why it occurred to me to start trying batch mode and see if I
could use udpsend or netsend as out-of-band communication to control
it.  It wouldn't have to start/stop an entire process or access the
disk at all.  It could all stay in memory waiting to run the long
analysis until the parent asks it to.

> > 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())

Thank you, I'll read through more of the sched_tick() and
sys_pollgui() code next.


> > Gesendet: Montag, 27. Januar 2020 um 02:20 Uhr
> > Von: "Charles Z Henry" 
> > An: Pd-List 
> > 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