[PD] How's Pd limited?

cyrille henry ch at chnry.net
Wed Feb 24 17:15:57 CET 2016



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
>



More information about the Pd-list mailing list