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