[PD] How's Pd limited?

[Lucas Cordiviola]

You can do somthing like MSP poly~ with Pd poly and switch~ or route and switch~.
The (64+64+64+13) example can be corrected by knowing when its going to end, ie sheduling the next one when that one is fired, as long as its longer than 1 block (64samples). You need to store the name of the file with the file lenght. then  somthing with the del object. better with alternating 2 players (readsf~, table or other).
Mensaje telepatico asistido por maquinas.

Date: Wed, 24 Feb 2016 18:44:00 +0000
From: peimankhosravi at gmail.com
To: ch at chnry.net
CC: pd-list at lists.iem.at
Subject: Re: [PD] How's Pd limited?

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 

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




_______________________________________________
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/b5144e72/attachment-0001.html>