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 <dmed...@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 <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> * >> >> On 24 February 2016 at 16:15, cyrille henry < <c...@chnry.net>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>dmed...@ucsd.edu < >>>> javascript:_e(%7B%7D,'cvml',' <dmed...@ucsd.edu>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/> >>>> http://spectralkimia.wordpress.com/>* >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pd-list@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@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@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> <http://lists.puredata.info/listinfo/pd-list> >> http://lists.puredata.info/listinfo/pd-list >> >> > > > _______________________________________________pd-l...@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