[PD] How's Pd limited?

Wed Feb 24 21:41:34 CET 2016

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).

On Wed, Feb 24, 2016 at 2:58 PM, David Medine <dmedine at ucsd.edu> wrote:

> 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
> > 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>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>>
>>>> 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>dmedine at ucsd.edu <
>>>> javascript:_e(%7B%7D,'cvml',' <dmedine at ucsd.edu>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://peimankhosravi.co.uk/miscposts.rss><
>>>> <http://spectralkimia.wordpress.com/>
>>>> http://spectralkimia.wordpress.com/>*
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pd-list at lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> <http://lists.puredata.info/listinfo/pd-list>
>>>> 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>
>>> 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>
>> 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
>
>
>
> _______________________________________________
> 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/0a51074c/attachment.html>