how about the "tanhauser" (heavy audio tools now) compiler, that can compile patches to C code, and then, on another step on this chain, we could make it an external?
looks like a window into a gen~ like idea, but I might be far off cheers 2016-02-24 21:59 GMT-03:00 Jonathan Wilkes via Pd-list <[email protected] >: > > It sounds very difficult, but I imagine gen~ does something like that. > > I don't think the payoff is big enough to justify the development, unless > what gets compiled are good old signal and/or control object chains that > everybody is already familiar with. > > That's what happened with Javascript engines. It's quite extraordinary > to see what can be done in the browser be people who have no idea > what V8 is doing under the hood. At the same time the people > who are experts are building high-quality frameworks in a few years > that would have previously taken a decade to develop. And I can play > old arcade games inside my browser. Everybody wins. > > One the other hand, that's pretty damned complex and expensive > development. Outside of trivial cases like a chain of unary op signal > objects with single connections, I have no idea how one would optimize > Pd patches, much less on the fly. But surely the first step is better > realtime analysis tools, so we can quickly know where the bulk of the > CPU time is spent. > > -Jonathan > > > > > > On Wednesday, February 24, 2016 6:18 PM, Brian Fay < > [email protected]> wrote: > > > The issue with blocking is that you don't have fine-grained control of an > audio, process, right? If you want that level of fine-grained control, you > either need to explicitly set the blocksize to 1 in your patch/sub-patch, > or you need to actually dig into the C code for the externals and change > the logic there (which requires you write C code, recompile things, restart > Pd...). > > Theoretically, there could be a way to swap out the code for an external > while Pd is running, rather than restarting Pd. Still, you'd have to write > C and pray that you didn't introduce some terrible bug. > > But theoretically, instead of writing externals in C, couldn't we come up > with a high-level representation of a Pd external in a visual programming > environment similar to Pd? Then we could compile that down to an external, > and actually use it in our Pd patch, without actually reloading Pd. It > sounds very difficult, but I imagine gen~ does something like that. > > For reference, I believe Extempore provides the ability to edit and > replace a low-level audio process while the program is running (I'll have > to rewatch some conference videos to confirm that). > > On Wed, Feb 24, 2016 at 3:41 PM, Matt Barber <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected] > > 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 < <[email protected]>[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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 < <[email protected]>[email protected] < > javascript:_e(%7B%7D,'cvml',' <[email protected]>[email protected]');>> > > 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/>* > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > <http://lists.puredata.info/listinfo/pd-list> > http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > <http://lists.puredata.info/listinfo/pd-list> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] 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 > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
