Re: [PD] pd~ binary for max/msp
Em dom., 26 de jan. de 2020 às 08:58, Miller Puckette via Pd-list < pd-list@lists.iem.at> escreveu: > 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. > > 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.) I always thought this was an amazing idea, would love to try it out! ___ 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
Hi, Messages can be sent to a subprocess from a parent--but I had to start using udpsend to send messages back. You can send messages from the subprocess to the parent process with [stdout], check the help file of [pd~]. 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. Note that the subprocess is slaved to the parent process, so if the subprocess blocks, the parent also blocks. You can absorb occasional CPU spikes by setting "-fifo" to a high value, but you can never make it 100% non-blocking. Now that you've described your setup, I think you should rather run a seperate instance of Pd (probably with the "-nrt" flag) and communicate with [netsend]/[netreceive] as you're already doing. Currently, there's no Vanilla way to start external processes (yet), but you can either find an external (there are some, but I keep forgetting the name) or start both instances together with a simple shell script. Finally, you can simplify the communication by using TCP, because with [netreceive] - without "-u" - you just have to listen for an incoming message and then you can send a reply with the [send( method - no need to open another socket! Christof On 28.01.2020 06:22, Charles Z Henry wrote: 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
[PD] strange behavior with line~, vline~ and DAC samplerate
Hello, On my computer linux pd 0.50 + ALSA, I have a strange behavior with vline~ and line~ : for DACs set with samplerates < 44100Hz e.g. @ samplerate = 22050, the ramps go twice faster as scheduled. everything ok for samplerates = 48000, 96000 hz Tested with help patches for vline~ and line~ I cannot further investigate for now. Can someone confirm that ? Thanks ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [pd] sending lists via [comport]
Dear list, does anyone know how to send the different values of each line from the sample below to [comport] as a list, strip this list in [pd] and route the values to their different destinations? The data comes via Arduino from a pixy cam. Here is a sample from Arduino's serial monitor: Detected 6 block 0: sig: 2 x: 273 y: 36 width: 42 height: 5 index: 41 age: 18 block 1: sig: 1 x: 272 y: 187 width: 36 height: 4 index: 37 age: 18 block 2: sig: 1 x: 266 y: 151 width: 28 height: 4 index: 226 age: 71 block 3: sig: 1 x: 274 y: 109 width: 20 height: 4 index: 155 age: 124 block 4: sig: 2 x: 280 y: 48 width: 32 height: 2 index: 223 age: 72 block 5: sig: 1 x: 240 y: 136 width: 24 height: 2 index: 52 age: 5 At the moment [comport] receives all the numbers one after another (e.g. 2 273 36 42 5 41 18 ...), so that it is impossible for me to tell [pd] which number should go where. I kept checking the internet for a solution for several days which did not bring me any further, so I hope that someone in the [pd] community could give me a clou. Thanks Maik -- __ Dr. Maik Hester Musiker, Musikwissenschaftler, Akkordeon-Restaurator Himmelohstraße 23 D-58454 Witten ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] [pd] sending lists via [comport]
if the incoming data all have the same structure (i.e. the strings of numbers have the same lenght), you could group them in lists and then use unpack to sort their destinations. like in the patch attached hth hans grouplist.pd Description: Binary data > Am 28.01.2020 um 23:25 schrieb Dr. Maik Hester : > > Dear list, > > does anyone know how to send the different values of each line from the > sample below to [comport] as a list, strip this list in [pd] and route > the values to their different destinations? > > The data comes via Arduino from a pixy cam. > > Here is a sample from Arduino's serial monitor: > > Detected 6 > block 0: sig: 2 x: 273 y: 36 width: 42 height: 5 index: 41 age: 18 > block 1: sig: 1 x: 272 y: 187 width: 36 height: 4 index: 37 age: 18 > block 2: sig: 1 x: 266 y: 151 width: 28 height: 4 index: 226 age: 71 > block 3: sig: 1 x: 274 y: 109 width: 20 height: 4 index: 155 age: 124 > block 4: sig: 2 x: 280 y: 48 width: 32 height: 2 index: 223 age: 72 > block 5: sig: 1 x: 240 y: 136 width: 24 height: 2 index: 52 age: 5 > > At the moment [comport] receives all the numbers one after another (e.g. > 2 273 36 42 5 41 18 ...), so that it is impossible for me to tell > [pd] which number should go where. > > I kept checking the internet for a solution for several days which did > not bring me any further, so I hope that someone in the [pd] community > could give me a clou. > > Thanks > Maik > > > > > -- > __ > Dr. Maik Hester > Musiker, Musikwissenschaftler, Akkordeon-Restaurator > Himmelohstraße 23 > D-58454 Witten > > > > > ___ > 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] [pd] sending lists via [comport]
Have you tried the abstractions in https://github.com/alexdrymonitis/Arduino_Pd? On 1/28/20, Dr. Maik Hester wrote: > Dear list, > > does anyone know how to send the different values of each line from the > sample below to [comport] as a list, strip this list in [pd] and route > the values to their different destinations? > > The data comes via Arduino from a pixy cam. > > Here is a sample from Arduino's serial monitor: > > Detected 6 > block 0: sig: 2 x: 273 y: 36 width: 42 height: 5 index: 41 age: 18 > block 1: sig: 1 x: 272 y: 187 width: 36 height: 4 index: 37 age: 18 > block 2: sig: 1 x: 266 y: 151 width: 28 height: 4 index: 226 age: 71 > block 3: sig: 1 x: 274 y: 109 width: 20 height: 4 index: 155 age: 124 > block 4: sig: 2 x: 280 y: 48 width: 32 height: 2 index: 223 age: 72 > block 5: sig: 1 x: 240 y: 136 width: 24 height: 2 index: 52 age: 5 > > At the moment [comport] receives all the numbers one after another (e.g. > 2 273 36 42 5 41 18 ...), so that it is impossible for me to tell > [pd] which number should go where. > > I kept checking the internet for a solution for several days which did > not bring me any further, so I hope that someone in the [pd] community > could give me a clou. > > Thanks > Maik > > > > > -- > __ > Dr. Maik Hester > Musiker, Musikwissenschaftler, Akkordeon-Restaurator > Himmelohstraße 23 > D-58454 Witten > > > > > ___ > 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] strange behavior with line~, vline~ and DAC samplerate
Am 28. Jänner 2020 23:18:01 MEZ schrieb Jean-Yves Gratius : >Hello, > >On my computer linux pd 0.50 + ALSA, I have a strange behavior with >vline~ and line~ : > >for DACs set with samplerates < 44100Hz > >e.g. @ samplerate = 22050, the ramps go twice faster as scheduled. where and how do you set the samplerate! does your soundcard allow to change the sr? mfg.hft.fsl IOhannes ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] Fwd: strange behavior with line~, vline~ and DAC samplerate
Sorry for the noise, The trouble occured for samplerates that are not supported by my soundcard Forwarded Message Subject:strange behavior with line~, vline~ and DAC samplerate Date: Tue, 28 Jan 2020 23:18:01 +0100 From: Jean-Yves Gratius To: pd-list@lists.iem.at Hello, On my computer linux pd 0.50 + ALSA, I have a strange behavior with vline~ and line~ : for DACs set with samplerates < 44100Hz e.g. @ samplerate = 22050, the ramps go twice faster as scheduled. everything ok for samplerates = 48000, 96000 hz Tested with help patches for vline~ and line~ I cannot further investigate for now. Can someone confirm that ? Thanks ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
