<div dir="ltr">I wrote pix_share_read/write exactly for this purpose.  It only moves pixes between processes but that is the heavy CPU load most of the time.  Multiple GEM instances can read from the same write (or at least did when I used it), so one GEM could capture from a video source, another compress the image to disk and a third instance display it on screen.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 31, 2019 at 11:37 AM Csaba Láng <<a href="mailto:langcsaba@gmail.com">langcsaba@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi dearest list,<div><br></div><div>I am looking for a multiprocessing solution for GEM itself.</div><div>What I found from Miller's paper: </div><div><a href="http://www.pdpatchrepo.info/hurleur/multiprocessing.pdf" target="_blank">http://www.pdpatchrepo.info/hurleur/multiprocessing.pdf</a><br></div><div>clearly deals with only audio multiprocessing as the object pd~ indicates its usage.</div><div>Is there any method to spread GEM calculations among 4-8 processors?</div><div><br></div><div>Best,</div><div><br></div><div>Popesz</div></div>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div>