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 <peimankhosr...@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> > <http://peimankhosravi.co.uk/miscposts.rss> > <http://spectralkimia.wordpress.com/>* > > On 24 February 2016 at 16:15, cyrille henry <c...@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.b...@gmail.com <mailto:composer.samuel.b...@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 <dmed...@ucsd.edu >>> <javascript:_e(%7B%7D,'cvml','dmed...@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@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> > > > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
