[PD] How's Pd limited?
David Medine
dmedine at ucsd.edu
Wed Feb 24 20:58:09 CET 2016
This doesn't answer Matt's question at all (apologies), but just as a
clarification, ChucK /does /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.
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).
Anyway, in my opinion, the block thing isn't a limit to Pd, but a limit
to real-time digital signal processing.
On 2/24/2016 11:27 AM, Matt Barber wrote:
> 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.
>
> On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi
> <peimankhosravi at gmail.com <mailto:peimankhosravi at gmail.com>> wrote:
>
> 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.
>
>
> *www.peimankhosravi.co.uk <http://www.peimankhosravi.co.uk> *
>
> On 24 February 2016 at 16:15, cyrille henry <ch at chnry.net
> <mailto:ch at chnry.net>> wrote:
>
>
>
> Le 24/02/2016 16:50, peiman khosravi a écrit :
>
> One great advantage of maxmsp is gen, which gives you
> sample-level patching with the possibility of a one-sample
> delay.
>
>
> you can use [block~ 1 1 1] in a pd subpatch.
>
> cheers
> c
>
>
> P
>
> On Tuesday, February 23, 2016, Samuel Burt
> <composer.samuel.burt at gmail.com
> <mailto:composer.samuel.burt at gmail.com>
> <mailto:composer.samuel.burt at gmail.com
> <mailto:composer.samuel.burt at gmail.com>>> wrote:
>
> David,
>
> 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.
>
> 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).
>
> 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.
>
> 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?
>
> Sam
>
>
>
>
>
>
> Message: 4
> Date: Tue, 23 Feb 2016 09:01:06 -0800
> From: david medine <dmedine at ucsd.edu
> <mailto:dmedine at ucsd.edu>
> <javascript:_e(%7B%7D,'cvml','dmedine at ucsd.edu
> <mailto:dmedine at ucsd.edu>');>>
>
> One thing I'd be interested in knowing about is
> what (if anything)
> someone tried to do in Pd, but couldn't given its
> limitations (apart
> from look/feel/convenience issues).
>
>
>
> --
>
> *www.peimankhosravi.co.uk
> <http://www.peimankhosravi.co.uk>
> <http://www.peimankhosravi.co.uk>
> <http://peimankhosravi.co.uk/miscposts.rss><http://spectralkimia.wordpress.com/>*
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing
> list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160224/e368ae0e/attachment.html>
More information about the Pd-list
mailing list