<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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>
<br>
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>
<br>
Anyway, in my opinion, the block thing isn't a limit to Pd, but a
limit to real-time digital signal processing.<br>
<br>
<br>
<div class="moz-cite-prefix">On 2/24/2016 11:27 AM, Matt Barber
wrote:<br>
</div>
<blockquote
cite="mid:CAOrke7GZOk1tuPouEmY-=dbc-yVuqQYbneQpjX_oV8gxbFu8Tw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div class="gmail_default"
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 class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Feb 24, 2016 at 1:44 PM, peiman
khosravi <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:peimankhosravi@gmail.com" target="_blank">peimankhosravi@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 class="gmail_default"
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>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
</div>
<div><font size="2" face="comic sans ms,
sans-serif"><b><a moz-do-not-send="true"
href="http://www.peimankhosravi.co.uk"
target="_blank">www.peimankhosravi.co.uk</a>
</b></font></div>
</div>
</div>
</div>
</div>
</div>
<div>
<div class="h5">
<br>
<div class="gmail_quote">On 24 February 2016 at 16:15,
cyrille henry <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ch@chnry.net" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:ch@chnry.net">ch@chnry.net</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
Le 24/02/2016 16:50, peiman khosravi a écrit :<br>
<blockquote class="gmail_quote" 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>
<br>
</blockquote>
<br>
</span>
you can use [block~ 1 1 1] in a pd subpatch.<br>
<br>
cheers<br>
c<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
P<span><br>
<br>
On Tuesday, February 23, 2016, Samuel Burt
<<a moz-do-not-send="true"
href="mailto:composer.samuel.burt@gmail.com"
target="_blank">composer.samuel.burt@gmail.com</a>
<mailto:<a moz-do-not-send="true"
href="mailto:composer.samuel.burt@gmail.com"
target="_blank">composer.samuel.burt@gmail.com</a>>>
wrote:<br>
<br>
David,<br>
<br>
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>
<br>
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>
<br>
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>
<br>
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>
<br>
Sam<br>
<br>
<br>
<br>
<br>
<br>
<br>
Message: 4<br>
Date: Tue, 23 Feb 2016 09:01:06 -0800<br>
</span>
From: david medine <<a
moz-do-not-send="true"
href="mailto:dmedine@ucsd.edu" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dmedine@ucsd.edu">dmedine@ucsd.edu</a></a>
<<a class="moz-txt-link-freetext" href="javascript:_e(%7B%7D,'cvml">javascript:_e(%7B%7D,'cvml</a>','<a
moz-do-not-send="true"
href="mailto:dmedine@ucsd.edu" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dmedine@ucsd.edu">dmedine@ucsd.edu</a></a>');>><span><br>
<br>
One thing I'd be interested in knowing
about is what (if anything)<br>
someone tried to do in Pd, but
couldn't given its limitations (apart<br>
from look/feel/convenience issues).<br>
<br>
<br>
<br>
--<br>
<br>
</span>
*<a moz-do-not-send="true"
href="http://www.peimankhosravi.co.uk"
rel="noreferrer" target="_blank">www.peimankhosravi.co.uk</a>
<<a moz-do-not-send="true"
href="http://www.peimankhosravi.co.uk"
rel="noreferrer" target="_blank">http://www.peimankhosravi.co.uk</a>>
<<a moz-do-not-send="true"
href="http://peimankhosravi.co.uk/miscposts.rss"
rel="noreferrer" target="_blank">http://peimankhosravi.co.uk/miscposts.rss</a>><<a
moz-do-not-send="true"
href="http://spectralkimia.wordpress.com/"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://spectralkimia.wordpress.com/">http://spectralkimia.wordpress.com/</a></a>>*<span><br>
<br>
<br>
<br>
_______________________________________________<br>
<a moz-do-not-send="true"
href="mailto:Pd-list@lists.iem.at"
target="_blank">Pd-list@lists.iem.at</a>
mailing list<br>
UNSUBSCRIBE and account-management -> <a
moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/pd-list"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a></a><br>
<br>
</span></blockquote>
<div>
<div>
<br>
_______________________________________________<br>
<a moz-do-not-send="true"
href="mailto:Pd-list@lists.iem.at"
target="_blank">Pd-list@lists.iem.at</a>
mailing list<br>
UNSUBSCRIBE and account-management -> <a
moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/pd-list"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a></a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
<a moz-do-not-send="true" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a>
mailing list<br>
UNSUBSCRIBE and account-management -> <a
moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/pd-list"
rel="noreferrer" target="_blank"><a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a></a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
</body>
</html>