<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yiv0006530398"><div id="yui_3_16_0_1_1456332763893_3031"><div id="yui_3_16_0_1_1456332763893_3030" style="color:#000;background-color:#fff;font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"><div id="yui_3_16_0_1_1456332763893_3202">I think one of the big limitations is a difficulty in turning "hot" code "cool".</div><div id="yui_3_16_0_1_1456332763893_4122"><br></div><div id="yui_3_16_0_1_1456332763893_3156">For example, suppose the [hungry~] abstraction is at the heart of your patch but it consumes a lot of CPU. What do you do?</div><div id="yui_3_16_0_1_1456332763893_3201"><br></div><div id="yui_3_16_0_1_1456332763893_3196">Typically the process involves only two steps:</div><div id="yui_3_16_0_1_1456332763893_4121" dir="ltr">1. make esoteric changes that marginally decrease the CPU load</div><div id="yui_3_16_0_1_1456332763893_4107" dir="ltr">2. give up and port [hungry~] to a C or C++ external</div><div id="yui_3_16_0_1_1456332763893_4147" dir="ltr"><br></div><div id="yui_3_16_0_1_1456332763893_4149" dir="ltr">#1 decreases readability, and #2 decreases portability (and hopefully readability as well).<br></div><div id="yui_3_16_0_1_1456332763893_4108"><br></div><div id="yui_3_16_0_1_1456332763893_4151">Parallelization may be a means to address this, but it is a means and not an end. In any case the first place to start is <br></div><div dir="ltr">to profile CPU usage and patch performance, as well as signal and object performance within the patch. Pd needs tools <br></div><div id="yui_3_16_0_1_1456332763893_4109" dir="ltr">to accurately measure which classes and abstractions are responsible when a patch runs hot.<br></div><div id="yui_3_16_0_1_1456332763893_4110" dir="ltr"><br></div><div id="yui_3_16_0_1_1456332763893_4111" dir="ltr">Desiredata apparently added some functionality to do that but it was apparently buggy and didn't get a lot of testing. Anyhow, <br></div><div id="yui_3_16_0_1_1456332763893_4112" dir="ltr">these tools are crucial to a sensible discussion of parallelization-- without them we can only measure object performance with <br></div><div id="yui_3_16_0_1_1456332763893_4113" dir="ltr">very blunt tools.</div><div id="yui_3_16_0_1_1456332763893_4114" dir="ltr"><br></div><div id="yui_3_16_0_1_1456332763893_4115" dir="ltr">-Jonathan<br></div></div></div></div><div class=".yiv0006530398yahoo_quoted"> <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 class="qtdSeparateBR"><br><br></div><div class="yiv0006530398yqt1747832587" id="yiv0006530398yqt14811"><div dir="ltr"><font face="Arial" size="2"> On Wednesday, February 24, 2016 10:53 AM, peiman khosravi <peimankhosravi@gmail.com> wrote:<br clear="none"></font></div> <br clear="none"><br clear="none"> <div class="yiv0006530398y_msg_container"><div id="yiv0006530398"><div>One great advantage of maxmsp is gen, which gives you sample-level patching with the possibility of a one-sample delay.<div><br clear="none"></div><div>P<br clear="none"><br clear="none">On Tuesday, February 23, 2016, Samuel Burt <<a rel="nofollow" shape="rect" ymailto="mailto:composer.samuel.burt@gmail.com" target="_blank" href="mailto:composer.samuel.burt@gmail.com">composer.samuel.burt@gmail.com</a>> wrote:<br clear="none"><div class="yiv0006530398yqt0825681646" id="yiv0006530398yqt24291"><blockquote class="yiv0006530398gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr"><div>David,</div><div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div>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).</div><div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div>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?</div><div><br clear="none"></div><div>Sam</div><div><br clear="none"></div><div><br clear="none"></div><div><br clear="none"></div><div><br clear="none"></div><br clear="none"><div class="yiv0006530398gmail_quote"><blockquote class="yiv0006530398gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br clear="none">
Message: 4<br clear="none">
Date: Tue, 23 Feb 2016 09:01:06 -0800<br clear="none">
From: david medine <<a href="" rel="nofollow" shape="rect">dmedine@ucsd.edu</a>><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">
</blockquote></div></div>
</blockquote></div></div><br clear="none"><br clear="none">-- <br clear="none"><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" target="_blank" href="http://www.peimankhosravi.co.uk/">www.peimankhosravi.co.uk</a> <a rel="nofollow" shape="rect" target="_blank" href="http://peimankhosravi.co.uk/miscposts.rss"></a><a rel="nofollow" shape="rect" target="_blank" href="http://spectralkimia.wordpress.com/"></a></b></font></div></div></div></div><br clear="none"></div></div><br clear="none"><div class="yiv0006530398yqt0825681646" id="yiv0006530398yqt95788">_______________________________________________<br clear="none"><a rel="nofollow" shape="rect" ymailto="mailto:Pd-list@lists.iem.at" target="_blank" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a rel="nofollow" shape="rect" target="_blank" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br clear="none"><br clear="none"></div></div> </div> </div> </div></div></body></html>