[PD] How's Pd limited?
brbrofsvl at gmail.com
Wed Feb 24 20:27:06 CET 2016
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
On Wed, Feb 24, 2016 at 1:44 PM, peiman khosravi <peimankhosravi at gmail.com>
> 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> 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.
>>> On Tuesday, February 23, 2016, Samuel Burt <
>>> composer.samuel.burt at gmail.com <mailto:composer.samuel.burt at gmail.com>>
>>> 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?
>>> Message: 4
>>> Date: Tue, 23 Feb 2016 09:01:06 -0800
>>> From: david medine <dmedine at ucsd.edu
>>> One thing I'd be interested in knowing about is what (if
>>> someone tried to do in Pd, but couldn't given its limitations
>>> from look/feel/convenience issues).
>>> *www.peimankhosravi.co.uk <http://www.peimankhosravi.co.uk> <
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list