18 Aug
2010
18 Aug
'10
5:34 p.m.
On Wed, 2010-08-18 at 16:27 +0100, João de Brito Vidigal wrote:
So... I'll try the udp I guess... but how do I do that?
I'd use [netsend 1] on the sender and [netreceive <portnuber> 1] on the sender. You can use 'localhost' as host, if both are running on the same box.
Roman
2010/8/18 Pedro Lopes pedro.lopes@ist.utl.pt p.s.: notice that my 40 sockets rarely have packets on them, its not poling intensive. Just from time to time, when users change stuff around..
2010/8/18 Roman Haefeli <reduzent@gmail.com> On Wed, 2010-08-18 at 15:34 +0100, João de Brito Vidigal wrote: > Since I'm doing this to ease multiple video processing (up to 18 short > videos), do you think it's ok to open several different net ports? or > will it then get stuck with that!? Most of the net classes in Pd I am aware of are not threaded, so yeah, this theoretically could be an issue. In practice it might not. The worst that can happen is when the receiving end point disappears without the sending end point noticing it. In such a case, the buffer of the sender gets filled and when it has reached the maximum, it blocks Pd completely. If both the sender and the receiver are running on the same box this very unlikely to happen. But still be aware of the buffer: If you send a lot of data, you might still be able to fill it, which would again cause drop outs. But again, if both are on the same box, it's unlikely you hit some bandwidth limit. Now after writing this, I realize that problems relating to buffering are specifcic to TCP. There is no need to do buffering for sending UDP, so using UDP should even be less likely to cause troubles. Roman > 2010/8/17 Mario Mora <maredmo@gmail.com> > Hi Joao > > > You can achieve that by starting one instance of pd in the > usual way (for audio process by example) and the other one > using the terminal app , writing there the adress to the app > and starting it with the ./Pd-extended command by > example....it is recommended that you start the pd instace for > video (gem) with -noaudio flag or, alternatively desctivating > the audio in the menu of the app. > > > I have used that approach with success for audio and video > processing in real-time like this: > http://www.vimeo.com/12532169 > > > hope it helps > > > bests > > > Mario > > > > 2010/8/17 João de Brito Rocha Reis Vidigal > <jbvidigal@gmail.com> > I'm using OSX > I want to sync 2 PD's (not 2 PD patches). One to > control sound the other to control video (GEM). > > > "(your OS can tell you in which CPU a process is > running, there are several cmd tools in linux for > that)" > can OSX do it as well? > > > On 17 Aug 2010, at 16:15, Pedro Lopes wrote: > > Can you clarify this a bit further? > > What are the two things you want to sync? (Arduino and > pd? No need for OSC for that...but very do-able) > > (your OS can tell you in which CPU a process is > running, there are several cmd tools in linux for > that) > > > Best regards, > Pedro > > 2010/8/17 João de Brito Rocha Reis Vidigal > <jbvidigal@gmail.com> > Any idea on how to get the first Pd working > with one processor and the second with the > other? > > I'm using the Arduino firmata to trigger both > sound and video. I think I can't open twice > the same port! So how can I use the OSC then > to sync the triggering!? > > > > On 17 Aug 2010, at 16:05, Mathieu Bouchard > wrote: > > On Tue, 17 Aug 2010, Pierre Massat wrote: > > > Does this mean that in Linux and on a dual > core machine one instance of Pd only uses one > processor? > > No, it doesn't mean that. > > But all the messages and signals circulate in > a since thread (on a single cpu) unless you > use special tools to split it into several > threads. > > Then there is the "client process", which > "own" the patch windows and the main window. > This runs separately. > > Also, [soundfiler], some GEM input/output > classes, and much of PDP, can run in an > alternate thread. > > > Is there a way to know which processor it > uses, and whether it always uses the same > processor? > > No idea... I still run a single-core all day > long. > > _ _ __ ___ _____ ________ _____________ > _____________________ ... > | Mathieu Bouchard, Montréal, Québec. > téléphone: +1.514.383.3801 > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > -- > Pedro Lopes (ongoing MSc) > contact: pedro.lopes@ist.utl.pt > website: http://web.ist.utl.pt/Pedro.Lopes > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Pedro Lopes (ongoing MSc) contact: pedro.lopes@ist.utl.pt website: http://web.ist.utl.pt/Pedro.Lopes