<div dir="ltr">how about the "tanhauser" (heavy audio tools now) compiler, that can compile patches to C code, and then, on another step on this chain, we could make it an external?<div><br></div><div>looks like a window into a gen~ like idea, but I might be far off</div><div><br></div><div>cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-24 21:59 GMT-03:00 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>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;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"><span class=""><div>> It sounds very difficult, but I imagine gen~ does something like that.</div><div><br></div></span><div>I don't think the payoff is big enough to justify the development, unless <br></div><div>what gets compiled are good old signal and/or control object chains that <br></div><div dir="ltr">everybody is already familiar with.</div><div dir="ltr"><br></div><div>That's what happened with Javascript engines.  It's quite extraordinary <br></div><div dir="ltr">to see what can be done in the browser be people who have no idea <br></div><div dir="ltr">what V8 is doing under the hood.  At the same time the people <br></div><div dir="ltr">who are experts are building high-quality frameworks in a few years <br></div><div dir="ltr">that would have previously taken a decade to develop.  And I can play <br></div><div dir="ltr">old arcade games inside my browser.  Everybody wins.</div><div dir="ltr"><br></div><div dir="ltr">One the other hand, that's pretty damned complex and expensive <br></div><div dir="ltr">development.  Outside of trivial cases like a chain of unary op signal <br></div><div dir="ltr">objects with single connections, I have no idea how one would optimize <br></div><div dir="ltr">Pd patches, much less on the fly.  But surely the first step is better <br></div><div dir="ltr">realtime analysis tools, so we can quickly know where the bulk of the <br></div><div dir="ltr">CPU time is spent.<span class="HOEnZb"><font color="#888888"><br> </font></span></div><span class="HOEnZb"><font color="#888888"><div dir="ltr"><br></div><div dir="ltr">-Jonathan<br></div></font></span><div><div class="h5"><div dir="ltr"><br> </div><div dir="ltr"><br></div><div dir="ltr"><br> </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 Wednesday, February 24, 2016 6:18 PM, Brian Fay <<a href="mailto:ovaltinevortex@gmail.com" target="_blank">ovaltinevortex@gmail.com</a>> wrote:<br></font></div>  <br><br> <div><div><div><div dir="ltr">The issue with blocking is that you don't have fine-grained control of an audio, process, right? If you want that level of fine-grained control, you either need to explicitly set the blocksize to 1 in your patch/sub-patch, or you need to actually dig into the C code for the externals and change the logic there (which requires you write C code, recompile things, restart Pd...).<div><br clear="none"></div><div>Theoretically, there could be a way to swap out the code for an external while Pd is running, rather than restarting Pd. Still, you'd have to write C and pray that you didn't introduce some terrible bug.</div><div><br clear="none"></div><div>But theoretically, instead of writing externals in C, couldn't we come up with a high-level representation of a Pd external in a visual programming environment similar to Pd? Then we could compile that down to an external, and actually use it in our Pd patch, without actually reloading Pd. It sounds very difficult, but I imagine gen~ does something like that.<br clear="none"><div><br clear="none"></div><div>For reference, I believe Extempore provides the ability to edit and replace a low-level audio process while the program is running (I'll have to rewatch some conference videos to confirm that). </div></div></div><div><br clear="none"><div><div>On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>></span> wrote:<br clear="none"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif">OK, now I'm having trouble even imagining how an unblocked audio model could possibly behave (at least, as David points out, in a real-time context).</div></div><div><div><div><br clear="none"><div>On Wed, Feb 24, 2016 at 2:58 PM, David Medine <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>></span> wrote:<br clear="none"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div>
    This doesn't answer Matt's question at all (apologies), but just as
    a clarification, ChucK <i>does </i>block audio. It's just that
    ChucK always blocks at the minimum size of 1 sample per block. 1 is
    still a block size though, and it still implies the same problems
    associated with order of operations, feedback, interpolating control
    input, and parallelization that a block size of 64 does. <br clear="none">
    <br clear="none">
    Also, maybe this has already been pointed out on this thread, but
    block 1 is super slow because it means that you have to load all
    your DSP functions onto the CPU cache every 1/SR seconds instead of
    64/SR seconds. Blocking by 64 buys a lot. Having a locally
    adjustable block size is a great feature (that ChucK lacks) because
    you can do it for special needs cases (like variable delay patches,
    for example).<br clear="none">
    <br clear="none">
    Anyway, in my opinion, the block thing isn't a limit to Pd, but a
    limit to real-time digital signal processing.<div><div><br clear="none">
    <br clear="none">
    <br clear="none">
    <div>On 2/24/2016 11:27 AM, Matt Barber
      wrote:<br clear="none">
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div style="font-family:verdana,sans-serif">Are there any other DSP
          environments besides ChucK that don't block audio? Last time I
          tried ChucK (2012?) its efficiency was still abysmal. [block~
          1] definitely takes a hit, but it's usually possible to
          minimize how much of the DSP chain is actually blocked at 1. I
          guess with Csound you can specify a k-rate equal to the sample
          rate which is also effectively a single sample block. I
          haven't ever used Csound in a real-time context, and most of
          what I do with it compiles much more slowly than real time in
          any case.</div>
      </div>
      <div><br clear="none">
        <div>On Wed, Feb 24, 2016 at 1:44 PM, peiman
          khosravi <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:peimankhosravi@gmail.com" target="_blank">peimankhosravi@gmail.com</a>></span>
          wrote:<br clear="none">
          <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">
              <div style="font-family:arial,helvetica,sans-serif">You can
                do this with MSP's poly~ too but I'm guessing that the
                CPU costs are quite heavy. Moreover, there are operators
                in gen that are designed for low-level operations. <br clear="none">
              </div>
            </div>
            <div><br clear="all">
              <div>
                <div>
                  <div dir="ltr">
                    <div>
                      <div dir="ltr">
                        <div><br clear="none">
                        </div>
                        <div><font face="comic sans ms,                             sans-serif" size="2"><b><a rel="nofollow" shape="rect" href="http://www.peimankhosravi.co.uk/" target="_blank">www.peimankhosravi.co.uk</a>
                            </b></font></div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
              <div>
                <div>
                  <br clear="none">
                  <div>On 24 February 2016 at 16:15,
                    cyrille henry <span dir="ltr"><<a rel="nofollow" shape="rect" href="mailto:ch@chnry.net" target="_blank"></a><a rel="nofollow" shape="rect" href="mailto:ch@chnry.net" target="_blank">ch@chnry.net</a>></span>
                    wrote:<br clear="none">
                    <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br clear="none">
                        <br clear="none">
                        Le 24/02/2016 16:50, peiman khosravi a écrit :<br clear="none">
                        </span><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                          One great advantage of maxmsp is gen, which
                          gives you sample-level patching with the
                          possibility of a one-sample delay.<br clear="none">
                          <br clear="none">
                        </blockquote>
                        <br clear="none">
                      
                      you can use [block~ 1 1 1] in a pd subpatch.<br clear="none">
                      <br clear="none">
                      cheers<br clear="none">
                      c<br clear="none">
                      <br clear="none">
                      <br clear="none">
                      <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                        P<span><br clear="none">
                          <br clear="none">
                          On Tuesday, February 23, 2016, Samuel Burt
                          <<a rel="nofollow" shape="rect" href="mailto:composer.samuel.burt@gmail.com" target="_blank">composer.samuel.burt@gmail.com</a>
                          <mailto:<a rel="nofollow" shape="rect" href="mailto:composer.samuel.burt@gmail.com" target="_blank">composer.samuel.burt@gmail.com</a>>>
                          wrote:<br clear="none">
                          <br clear="none">
                              David,<br clear="none">
                          <br clear="none">
                              One thing I attempted and couldn't find a
                          solution for was the following, mostly owing
                          to the limitation of interfacing with a 64
                          sample block size.<br clear="none">
                          <br clear="none">
                              I wanted to have a directory of hundreds
                          of audio recordings. Each one would be a
                          single wavelength from an interesting sound,
                          like a bass clarinet, marimba, harpsichord,
                          tambourine, etc. Each would begin and end at a
                          zero crossing so you could chain them together
                          to make complex timbres. They could be chained
                          in sequence, randomized, or loaded in
                          meta-data-matched chunks. I ran into a problem
                          figuring out how to trigger the next sound
                          based on the ending of the last sound in a
                          sample accurate way. Sound file loading or
                          even buffer playback triggering waits until
                          the start of the next block size before it
                          updates. If you have a waveform that lasts 205
                          samples (64+64+64+13), you have a gap of 51
                          silent samples before the next waveform would
                          start. Not only do you not get the continuous
                          sound you want, this winds up creating a
                          periodic pattern with a frequency of 689 Hz
                          (44100/64).<br clear="none">
                          <br clear="none">
                              David, I like your idea "what (if
                          anything) someone tried to do in Pd, but
                          couldn't given its limitations". I think this
                          could be a wonderful challenge if we could
                          have a monthly thread like this where the best
                          minds among us come up with solutions to some
                          of the hardest conceptual challenges in Pd.<br clear="none">
                          <br clear="none">
                              I'm still struggling with loading dozens
                          of files, audio dropouts, and other similar
                          problems. Someone else expressed frustration
                          about Pd's single-threaded status. I too have
                          feared upgrading my computer based on the
                          limitations of current multicore processors
                          (although realistically I think we can all
                          look at the "turbo-boost" level or whatever
                          Intel calls it to determine where our
                          processor might run with a demanding patch. I
                          understand the fact that you can't run your
                          audio process on multiple cores, because it is
                          a linear process. It would be great if the GUI
                          could run on a second core, a process that
                          loads audio into memory could run on third
                          core, while GEM could automatically run on a
                          fourth core. I don't have any concept of how
                          feasible that would be, though. Does the GUI
                          in pd-l2orc run on a separate core?<br clear="none">
                          <br clear="none">
                              Sam<br clear="none">
                          <br clear="none">
                          <br clear="none">
                          <br clear="none">
                          <br clear="none">
                          <br clear="none">
                          <br clear="none">
                                  Message: 4<br clear="none">
                                  Date: Tue, 23 Feb 2016 09:01:06 -0800<br clear="none">
                        </span>
                                From: david medine <<a rel="nofollow" shape="rect" href="mailto:dmedine@ucsd.edu" target="_blank"></a><a rel="nofollow" shape="rect" href="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>
                        <<a rel="nofollow" shape="rect">javascript:_e(%7B%7D,'cvml</a>','<a rel="nofollow" shape="rect" href="mailto:dmedine@ucsd.edu" target="_blank"></a><a rel="nofollow" shape="rect" href="mailto:dmedine@ucsd.edu" target="_blank">dmedine@ucsd.edu</a>');>><span><br clear="none">
                          <br clear="none">
                                  One thing I'd be interested in knowing
                          about is what (if anything)<br clear="none">
                                  someone tried to do in Pd, but
                          couldn't given its limitations (apart<br clear="none">
                                  from look/feel/convenience issues).<br clear="none">
                          <br clear="none">
                          <br clear="none">
                          <br clear="none">
                          --<br clear="none">
                          <br clear="none">
                        </span>
                        *<a rel="nofollow" shape="rect" href="http://www.peimankhosravi.co.uk/" target="_blank">www.peimankhosravi.co.uk</a>
                        <<a rel="nofollow" shape="rect" href="http://www.peimankhosravi.co.uk/" target="_blank">http://www.peimankhosravi.co.uk</a>>
                        <<a rel="nofollow" shape="rect" href="http://peimankhosravi.co.uk/miscposts.rss" target="_blank">http://peimankhosravi.co.uk/miscposts.rss</a>><<a rel="nofollow" shape="rect" href="http://spectralkimia.wordpress.com/" target="_blank"></a><a rel="nofollow" shape="rect" href="http://spectralkimia.wordpress.com/" target="_blank">http://spectralkimia.wordpress.com/</a>>*<span><br clear="none">
                          <br clear="none">
                          <br clear="none">
                          <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"></a><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">
                        </span></blockquote>
                      <div>
                        <div>
                          <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"></a><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>
                      </div>
                    </blockquote>
                  </div>
                  <br clear="none">
                </div>
              </div>
            </div>
            <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"></a><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>
      <br clear="none">
      <fieldset></fieldset>
      <br clear="none">
      <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 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><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><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">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div>  </div> </div>  </div></div></div></div></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>