<div dir="ltr">a possible source of inspiration: "supernova a scalable parallel audio synthesis server for SuperCollider". It works great.<br><a href="http://tim.klingt.org/publications/icmc2011_supernova.pdf">http://tim.klingt.org/publications/icmc2011_supernova.pdf</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 2:58 PM, David Medine <span dir="ltr"><<a href="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    That is definitely true. Of course, we musicians need it more than
    most computer users out there...<br>
    <br>
    <div>On 2/24/2016 11:57 AM, Jonathan Wilkes
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px">I'd say a solution
        would deserve the nobel prize in computers. :)<br>
        <div><br>
        </div>
        <div>-Jonathan<br>
        </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 Wednesday,
                  February 24, 2016 11:40 AM, david medine
                  <a href="mailto:dmedine@ucsd.edu" target="_blank"><dmedine@ucsd.edu></a> wrote:<br>
                </font></div>
              <br>
              <br>
              <div>
                <div>
                  <div>
                    <div>Reading a
                      full inbox in a non-parallelized fashion leads to
                      cross posting. Sorry for the repost, but this
                      belongs on this thread.<br clear="none">
                      <br clear="none">
                      Yeah, but the problem here (automatic compute
                      resource distribution) isn't just with the actual
                      distribution. Control timing is a huge issue too.
                      If you have multiple voices of the same synth on
                      different threads, good luck playing a chord. It
                      will frequently be an arpeggio. If there are very
                      strict, predictable rules about the order of when
                      each voice computes and when it sleeps in order to
                      wait for new samples and control signals, this
                      problem vanishes, but then you are no longer
                      computing in parallel, and you might as well have
                      everything on one thread anyway. <br clear="none">
                      <br clear="none">
                      This is a <i>really</i> interesting problem. If
                      someone can solve it, she deserves the nobel prize
                      in computer music.<br clear="none">
                      <div><br clear="none">
                        On 2/24/16 5:59 AM, Christof Ressi wrote:<br clear="none">
                      </div>
                    </div>
                    <div>
                      <blockquote type="cite">
                        <pre>Another possibility for at least some degree of parallel audio processing, I guess, is to use streaming objects + several instances of Pd.  I tried out [udpsend~] and [udpreceive~] (taken from the "net" library in Pd extended) and they seem to work reliably. Of course there is some latency envolved and it's no practical solution for our future 100 core machines :-p.

What are in your experience the best methods for sharing audio via different Pd instances?
And does anyone know the current status of "Audio over OSC"? I found this paper from 2010 <a rel="nofollow" shape="rect" href="http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf" target="_blank">http://iem.kug.ac.at/fileadmin/media/iem/projects/2010/jaeger.pdf</a> 
 
Christof



</pre>
                        <blockquote type="cite">
                          <pre>Gesendet: Mittwoch, 24. Februar 2016 um 11:12 Uhr
Von: Jack <a rel="nofollow" shape="rect" href="mailto:jack@rybn.org" target="_blank"><jack@rybn.org></a>
An: <a rel="nofollow" shape="rect" href="mailto:pd-list@lists.iem.at" target="_blank">pd-list@lists.iem.at</a>
Betreff: Re: [PD] How's Pd limited?

Hello,

Le 24/02/2016 00:19, Matt Barber a écrit :
</pre>
                          <blockquote type="cite">
                            <pre>Can anyone explain more why [pd~] doesn't fulfill the desire for
parallel processing, and maybe provide an example of something outside
of Pd that does? I don't feel like I have a great handle on the design.
As Jonathan said, it seems like Pd's determinism constraint is a big
hurdle to clear, though it's already relaxed a bit with netsend/receive.
What are the main differences between running an instance of Pd as a
[pd~] slave to another instance, and running two instances that
communicate via netsend/receive and jack?
</pre>
                          </blockquote>
                          <pre>I think, the main difference is :
- with [pd~] your communication is synchronous
- with [netsend]/[netreceive] your communication is asynchronous

So (if i am right), if something is heavy to compute (more than 100% of
your CPU) in your subprocess with [pd~], your parent have to wait the
end of this computation. This is not the case with [netsend]/[netreceive].
++

Jack


</pre>
                          <blockquote type="cite">
                            <pre>On Tue, Feb 23, 2016 at 5:45 PM, David Medine <<a rel="nofollow" shape="rect" href="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>
<a rel="nofollow" shape="rect" href="mailto:dmedine@ucsd.edu" target="_blank"><mailto:dmedine@ucsd.edu></a>> wrote:

    I think we all need to learn more about multi-threading if we want
    to run real-time, modular, digital signal processing algorithms on
    multi-core machines. I, for one, can not think of any general,
    robust way to do this. In that sense, Pd's adherence to single
    threading is actually a very elegant solution to the problem.


    On 2/23/2016 12:25 PM, martin brinkmann wrote:

        On 22/02/16 02:49, Matti Viljamaa wrote:

            How do you think Pure Data is limited?

        for me the only real and important (i can think of at the
        moment) limitation is the block-based audio processing.
        to me this seems quite unnatural and inconvenient when dealing with
        digital audio. it kept me for a couple of years from using pd,
        though it
        is only a 'showstopper' in rather few cases, i found out.
        feedback in large/complex patches for example, since it
        is not very practical (or possible at all) to re-block
        everything to 1...

        what i tried but couldn't (yet): build a decent piano-roll
        editor (vanilla).

        and i believe too, pd has to 'learn' better multithreading to run
        adequately on our future machines with hundreds or even thousands of
        arm-cores...

        _______________________________________________
        <a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> <a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank"><mailto:Pd-list@lists.iem.at></a> mailing list
        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>



    _______________________________________________
    <a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> <a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank"><mailto:Pd-list@lists.iem.at></a> mailing list
    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>




_______________________________________________
<a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list
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>

</pre>
                          </blockquote>
                          <pre>_______________________________________________
<a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list
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>

</pre>
                        </blockquote>
                        <pre>_______________________________________________
<a rel="nofollow" shape="rect" href="mailto:Pd-list@lists.iem.at" target="_blank">Pd-list@lists.iem.at</a> mailing list
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>
</pre>
                      </blockquote>
                      <br clear="none">
                    </div>
                  </div>
                </div>
                <br>
                <div>_______________________________________________<br clear="none">
                  <a 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 shape="rect" href="http://lists.puredata.info/listinfo/pd-list" target="_blank"></a><a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br clear="none">
                </div>
                <br>
                <br>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">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>