<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Pd's constraints make the automatic allocation unlikely.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Read this:</div><div class="gmail_default" style=""><font face="verdana, sans-serif"><a href="http://puredata.info/community/conventions/convention09/puckette.pdf">http://puredata.info/community/conventions/convention09/puckette.pdf</a></font><br></div><div class="gmail_default" style=""><br></div><div class="gmail_default" style=""><font face="verdana, sans-serif">'Since at least 1990, users and critics of Max/FTS have
observed that it would be desirable for objects to be automatically
allocated to processors in a way that would minimize
the bandwidth of interconnections between the objects. This
would free the user from the cumbersome task of understanding
the actual flow of data between objects in the patch; the
software would automatically assess that.
This didn’t prove practical, for two reasons. First, as has
long been well known, one can’t compute the quantity of data
that will flow between any given pair of objects in a patch (at
least, not if the patching language is able to solve arbitrary
computing problems). Predicting how much data will flow
where is hopeless.
The second problem is that nobody has been able to make
an expressive patching language that doesn’t depend on objects
sharing data. In Max/FTS (and in Pd as well) this takes
the form of “named” objects such as arrays. Any automatic
distribution of patches that allows accessing arrays would have
to place every object that accesses any particular array on the
same processor, or else use some kind of locking mechanism
that would be unlikely to work in real time. Also, any situation
in which there is of recombination of message fanout
would require that both message paths be synchronized, i.e.,
that both message paths go through the same itinerary of processors
or be otherwise delay-equalized. In combination, these
constraints would require that, for complete transparency, almost
any interesting patch would have to reside on a single
processor. It appears to be an inescapable fact that multiprocessing
has non-hideable effects on the execution of “patches”
and can’t effectively be carried out without the user’s active
participation.'</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><br></div><div class="gmail_default" style=""><br></div><div class="gmail_default" style=""><font face="verdana, sans-serif">It might be easier if Pd used a system of buses for routing rather than arbitrarily drawn patch connections, or if a graphical patching environment had a good way of implementing something like SuperCollider's Synth, which works with a flexible node order but has relatively limited means of input and output. Here's what I see as the bare minimum of what we'd need to address to make your wish a reality:</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">1) Unit generators instantiated in Pd have to exist somewhere in a running patch to output. This is in distinction to SC3 and csound, where instances of Synths or instrument templates are instantiated and destroyed. In the latter two, the order of creation and destruction of instruments (and in csound, the order they're defined in the orchestra) matters a lot in the DSP graph, which makes it more predictable. SC3 also has user methods for ordering nodes.</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">2) Connections in Pd are flexible and arbitrarily complex, which makes the DSP graph a lot more ramified than a mixer model with buses, inserts, aux sends, etc., and therefore much less predictable in the abstract.</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">3) Pd is deterministic, which means that (as noted in the quote above), any memory sharing across threads would need to involve locks, which can be killer in real-time, not to mention difficult to scale and guarantee thread safety. [pd~] communicates via FIFO because it needs to be able to keep messages and audio in sync by block.</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif">I'm sure there's more.</font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><font face="verdana, sans-serif"><br></font></div><div class="gmail_default" style=""><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 11:07 PM, William Huston <span dir="ltr"><<a href="mailto:williamahuston@gmail.com" target="_blank">williamahuston@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>Slightly OT-- but related: <br>I'm going to throw out a wish-list item <br></div>which is probably impossible or very hard to implement,<br></div><br>Find a way for the DSP Graph compiler to naturally<br></div>break up the task into small chunks, which all use shared<br></div>memory in a thread-safe way, so that the PD job automagically<br></div>spreads itself out over available cores without any special <br></div>work by the programmer. <br><br></div><div>Now that I've got my big, fast, lots of ram, 6-core AMD<br></div><div>box running again, I notice that I can run MUCH larger<br></div><div>graphs there than on my Raspberry Pi. <br><br></div><div>But I think it's just a raw CPU speed, or Cache Speed, or<br></div><div>speed to RAM which matters, and not the number of cores.<br></div><div><br>I notice that on my Pi there seems to be two processes, one for<br></div><div>the GUI and one for the DSP. 2 cores are wasted unless I use<br></div><div>the [pd~] object, and I have to basically guess how to split up the job. <br><br></div><div>I know, I'm dreaming here....<br></div><div><br></div><div><br><br></div><br><div> <br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 10:57 PM, Lucas Cordiviola <span dir="ltr"><<a href="mailto:lucarda27@hotmail.com" target="_blank">lucarda27@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr"><div>And more,</div><div><br></div><div>A single thread calculation divided between 2 cores in its 1 core time is more stable.</div><div><br></div><div>1 0</div><div>0 1</div><div>1 0</div><div>0 1</div><div><br></div><div>transistors have more idle time.</div><span><br><font face="Courier New, Courier, Monospace" size="2">Mensaje telepatico asistido por maquinas.</font><br><br></span><div><hr>From: <a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a><br>Date: Thu, 31 Mar 2016 22:45:57 -0400<span><br>Subject: Re: [PD] DSP and Gem in the same instance of Pd<br></span>To: <a href="mailto:jancsika@yahoo.com" target="_blank">jancsika@yahoo.com</a><br>CC: <a href="mailto:lucarda27@hotmail.com" target="_blank">lucarda27@hotmail.com</a>; <a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a><div><div><br><br><div dir="ltr"><div style="font-family:verdana,sans-serif">Right, so the point of [pd~] is that the OS can now throw whatever is going on in the subprocess onto another core. The idea from what I've heard for Gem is that you can leave the DSP off in the [pd~] instance, run Gem from there (on another core, possibly). Then if together they would have maxed out one core they could split the work among two and proceed in time.</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">But if the problem is that Gem has to wait for something to happen elsewhere before it can proceed, it won't help. Kind of in the same way that running an infinite [until] loop on the subprocess will halt the main process, too.</div></div><div><br><div>On Thu, Mar 31, 2016 at 9:24 PM, Jonathan Wilkes via Pd-list <span dir="ltr"><<a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>></span> wrote:<br><blockquote style="border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div>But [cpu_hungry_hippo~] needs input from [pd~] in order to <br></div><div dir="ltr">compute its output. So [pd~] must send output before [cpu_hungry_hippo~] <br></div><div dir="ltr">can execute its perform routine.</div><div><div><div><span></span></div> <div><br><br></div><div style="display:block"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"><font face="Arial" size="2"> On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola <<a href="mailto:lucarda27@hotmail.com" target="_blank">lucarda27@hotmail.com</a>> wrote:<br></font></div> <br><br> <div><div><div><div dir="ltr"><div>Isn`t </div><div><br clear="none"></div><div>[pd~] <-- some dsp stuff going on in here </div><div><br clear="none"></div><div>To take advantage of multi-core CPUs?</div><br clear="none"><font face="Courier New, Courier, Monospace" size="2">Mensaje telepatico asistido por maquinas.</font><br clear="none"><br clear="none"><div><hr>Date: Fri, 1 Apr 2016 00:37:26 +0000<br clear="none">To: <a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>; <a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a><br clear="none">CC: <a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a><br clear="none">Subject: Re: [PD] DSP and Gem in the same instance of Pd<br clear="none">From: <a href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a><br clear="none"><br clear="none"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div dir="ltr">I'm not sure I understand [pd~]. Consider:</div><div dir="ltr"><br clear="none"></div><div dir="ltr">[foo~]</div><div dir="ltr">|</div><div dir="ltr">[pd~] <-- some dsp stuff going on in here<br clear="none"></div><div dir="ltr">|</div><div dir="ltr">[cpu_hungy_hippo~]</div><div dir="ltr"><br clear="none"></div><div dir="ltr">How does [pd~] help me in this case, as opposed to just putting the <br clear="none"></div><div dir="ltr">"dsp stuff" directly in the patch?<br clear="none"></div><div dir="ltr"><br clear="none"></div><div dir="ltr">And in general, how is the super-process able to anything <br clear="none"></div><div dir="ltr">other than block when waiting for output from [pd~]?<br clear="none"> </div><div dir="ltr"><br clear="none"></div><div dir="ltr">-Jonathan<br clear="none"></div><div dir="ltr"><br clear="none"></div></div></div></div><div> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div><br clear="none"><br clear="none"></div><div><div dir="ltr"><font face="Arial" size="2"> On Thursday, March 31, 2016 5:17 PM, Matt Barber <<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>> wrote:<br clear="none"></font></div> <br clear="none"><br clear="none"> <div><div><div><div dir="ltr"><div style="font-family:verdana,sans-serif">One other thing that's helped in an emergency is increasing Pd's audio buffer in the preferences.</div><div style="font-family:verdana,sans-serif"><br clear="none"></div><div style="font-family:verdana,sans-serif">One thing I've heard of but never tried is running Gem from a slave instance in [pd~]. I don't know enough about it to know whether this could work or why; it might just be a rain dance.</div></div><div><br clear="none"><div><div>On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span> wrote:<br clear="none"><blockquote style="border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:<br clear="none">
><br clear="none">
> Le 31/03/2016 11:19, Roman Haefeli a écrit :<br clear="none">
> ><br clear="none">
</span><span>> > BTW: Why does the graphics rendering|clock have precedence over the<br clear="none">
> > audio rendering (at least, it seems to be like that in Pure Data/Gem)? I<br clear="none">
> > guess most softwares do it the other way around, since clicks are much<br clear="none">
> > more noticeable than a frame being a few milliseconds late.<br clear="none">
><br clear="none">
> Gem have no precedence over audio : they both have the same priority.<br clear="none">
> when having priorities on audio, the openGL rendering did not have<br clear="none">
> fixed frame rate, and it's not possible any-more to have smooth hight<br clear="none">
> speed movement.<br clear="none">
><br clear="none">
> So, i like the way it is, even if it cause implementation problem.<br clear="none">
<br clear="none">
</span>Oh, now since I understand, I like the way it is, too ;-)<br clear="none">
<span><br clear="none">
> one possible explanation of your problem is that you are rendering a<br clear="none">
> 60 fps, and that openGL is sync on the 60fps screen.<br clear="none">
> You can have jitter between the 2 different 60fps clock. If Gem is<br clear="none">
> waiting for the screen, then everything (including audio) is on pause.<br clear="none">
<br clear="none">
</span>That is exactly what I was doing.<br clear="none">
<span><br clear="none">
> if this is the cause of your problem, then reduce Gem fps to 59, or<br clear="none">
> remove openGL syncro (sync to vblank).<br clear="none">
<br clear="none">
</span>This is exactly what helped (reducing fps to 59). Thanks for your sharp<br clear="none">
thinking.<br clear="none">
<span><font color="#888888"><br clear="none">
Roman<br clear="none">
<br clear="none">
</font></span><br clear="none">_______________________________________________<br clear="none">
<a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">
UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
<br clear="none"></blockquote></div><br clear="none"></div></div></div></div><br clear="none"><div>_______________________________________________<br clear="none"><a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br clear="none"><br clear="none"></div></div> </div> </div> </div></div></div><br clear="none">_______________________________________________
<a href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a></div> </div></div></div><br><br></div> </div> </div> </div></div></div></div></div><br>_______________________________________________<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="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div></div></div></div> </div></div>
<br>_______________________________________________<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="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div dir="ltr">--<br>
May you, and all beings<br>
be happy and free from suffering :)<br>
-- ancient Buddhist Prayer (Metta)<br></div></div></div></div>
</font></span></div>
</blockquote></div><br></div></div>