[PD] How's Pd limited?

[peiman khosravi]

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>
<http://peimankhosravi.co.uk/miscposts.rss>
<http://spectralkimia.wordpress.com/>*

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.
>
> 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
>> <javascript:_e(%7B%7D,'cvml','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/>*
>>
>>
>>
>> _______________________________________________
>> 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/c4603c84/attachment.html>